PDA

View Full Version : در رابطه با قفل (کار نکردن دستورات جداول دیگر داخل قفل)



intel_amd
جمعه 23 آبان 1393, 13:46 عصر
برای اینکه تا پایان انجام عملیات های مورد نظرم جدول user قفل بمونه به شکل زیر عمل میکنم اما insert کار نمیکنه که اگر دستورات قفل را پاک کنم insert کار میکنه و یا اینکه در هنگام قفل کردن جدول user کلیه جداولی که داخل قفل با آنها هم کار میکنم قفل کنم مثلا اینجا group , در این حالت هم insert عمل میکنه اما اشکال اینجاست که بی جهت جداولی که قفل کردنشان لزومی نداشت را مجبور میشوم قفل کنم چون من فقط تا پایان این عملیات نیاز داشتم جدول user قفل بمونه نه هیچ جدول دیگری


mysql_query("LOCK TABLES user WRITE");


$result = mysql_query("SELECT * from user", $con);


mysql_query("INSERT INTO group VALUES ('','reza','A','')");


mysql_query("UNLOCK TABLES");


این یک مثال است که این موضوع را نشان دهم

id1385
جمعه 23 آبان 1393, 13:56 عصر
فکر میکنم بدلیله اینکه توی اینسرت شما دارید یک رکورد جدید اضافه میکنید و اون موجودیتش هنگام قفل محرز نیست و بعد از اینکه مراحل انجام میشه تازه موجودیت پیدا میکنه و دستور قفل قبل از اینسرت جلوگیری میکنه از اجرای این فانکشن.

البته نظر من بود

intel_amd
جمعه 23 آبان 1393, 19:11 عصر
کسی نظری نداره؟! جناب eshpilen عجیبه چیزی ننوشت

eshpilen
جمعه 23 آبان 1393, 19:27 عصر
اون ‎$con چیه گذاشتی فقط برای کوئری SELECT؟ :متفکر:
میگم شاید یه ربطی داره!

id1385
جمعه 23 آبان 1393, 19:49 عصر
توی اینسرت نیازی به قفل کردن نیست حالا هی بگو ...

دوست عزیز این متنو بخون

Locking is required only when developing scripts that first read a value from a database and later write that value to the database. Locks are never required for self-contained insert, update, or delete operations such as updating a customer's details, adding a region to theregion table, or unconditionally deleting an inventory. Locking may not be required for all parts of a web database application: parts of the application can still be safely used without violating any locking conditions.


اونجا که خط کشیدم توضیح داده که کار بیهوده انجام ندید


اینجا هم در تایید صحبتهای دوست عزیزمون گفته که خود کرده را تدبیر نیست

SELECT, UPDATE, INSERT, or DELETE operations that don't useLOCKTABLES don't proceed if locks are held that would logically prevent their operation.


امیدوارم مفید بوده باشه

intel_amd
جمعه 23 آبان 1393, 20:20 عصر
اون ‎$con چیه گذاشتی فقط برای کوئری SELECT؟ :متفکر:
میگم شاید یه ربطی داره!

برای insert هم مثل select اون $con گذاشتم اما بازم فایده نکرد !

intel_amd
جمعه 23 آبان 1393, 20:26 عصر
توی اینسرت نیازی به قفل کردن نیست حالا هی بگو ...

دوست عزیز این متنو بخون

Locking is required only when developing scripts that first read a value from a database and later write that value to the database. Locks are never required for self-contained insert, update, or delete operations such as updating a customer's details, adding a region to theregion table, or unconditionally deleting an inventory. Locking may not be required for all parts of a web database application: parts of the application can still be safely used without violating any locking conditions.


اونجا که خط کشیدم توضیح داده که کار بیهوده انجام ندید


اینجا هم در تایید صحبتهای دوست عزیزمون گفته که خود کرده را تدبیر نیست

SELECT, UPDATE, INSERT, or DELETE operations that don't useLOCKTABLES don't proceed if locks are held that would logically prevent their operation.


امیدوارم مفید بوده باشه

دوست عزیز شما هم چه گیری دادی که برای Insert قفل لازم نیست !!
تا پایان عملیات مورد نظرم نباید جدول user باز شه وگرنه اشتباه پیش می آید
مثال : اول select کن از جدول user اگر رکوردی با id مورد نظر نبود آنگاه آن را insert کن , حالا چالش , وقتی یوزرهای زیادی این پردازش همزمان انجام بدن اول جدول یوزر قفل میکنیم بعد select میکنیم اگر رکوردی با id مورد نظر نبود میره که insert کنه اما قبلش داریم جدول یوزر باز میکنیم و کاربر دیگری هم هنوز تا insert نکردین پردازشش میبینه که اون رکورد نیست پس هم این هم اون رکورد مورد نظر را insert میکنن و این میشه 2 تا insert تکراری یک رکورد مهم که نباید تکراری بشه !
پس تا پایان کلیه عملیات های مورد نظرم نباید جدول user را باز کنم تا نگفتم کسی چیزی ازش بخونه وقتی به حالت سیف رسید میگم بخونن
حالا یک راهش اینه که کلیه جداولی که داخل قفل باهاشون کار میکنم هم علاوه بر جدول یوزر اونهارم قفل کنم , اینجوری کار میکنه و دقیق اما یک سری جدولی که نیاز به قفل نبود الکی این وسط قفل میکنم که یکم بهینگی پائین میاد

intel_amd
جمعه 23 آبان 1393, 20:45 عصر
فکر کنم دقت نمیکنید که جدول user را قفل کرده ام و رکورد را در جدول group میریزم و نمیریزد !

eshpilen
جمعه 23 آبان 1393, 20:48 عصر
توی این صفحه که بخشی از متنش رو id1385 در پستش گذاشته: http://www.brainbell.com/tutors/php/php_mysql/When_and_how_to_lock_tables.html
چنین آمده است:
If a user requires a lock, she must lock all tables used in the transaction
ترجمه: «اگر یک کاربر به یک قفل نیاز دارد، باید تمام جدول های استفاده شده در ترنزکشن را قفل کند»

من مطمئن نیستم ولی شاید قضیه همینه و شما باید تمام جدولهایی رو که بین LOCK TABLES و UNLOCK TABLES مورد دسترسی قرار میگیرن قفل کنید! البته برای خود من عجیب بود و تاحالا چنین چیزی رو نشنیده بودم و تاحالا مشابه چنین چیزی رو تست هم نکردم. احتمالش هست!

حالا اگر اصرار داشته باشیم که جدول دوم قفل نشه، شاید اگر کوئری مربوط به جدول دوم رو روی یک کانکشن MySQL جداگانه ارسال کنیم اونوقت دچار این محدودیت نشیم (البته باید توجه داشت که کانکشن جداگانه خودش هم بهرحال هزینه ای داره). بنده توصیه میکنم چنانچه ترافیک فوق العاده سنگین روی این جدولها ندارید و در عمل مشکلی از این بابت مشاهده نمیشه پس این ترفند رو استفاده نکنید و هر دو جدول رو قفل کنید.

ضمنا حتما میدونید که در همون یک دستور و یک کوئری LOCK TABLES میتونید چندتا جدول رو همزمان قفل کنید و نیازی به اجرای چند دستور جداگانه برای این کار ندارید.

intel_amd
جمعه 23 آبان 1393, 21:01 عصر
توی این صفحه که بخشی از متنش رو id1385 در پستش گذاشته: http://www.brainbell.com/tutors/php/php_mysql/When_and_how_to_lock_tables.html
چنین آمده است:
If a user requires a lock, she must lock all tables used in the transaction
ترجمه: «اگر یک کاربر به یک قفل نیاز دارد، باید تمام جدول های استفاده شده در ترنزکشن را قفل کند»

من مطمئن نیستم ولی شاید قضیه همینه و شما باید تمام جدولهایی رو که بین LOCK TABLES و UNLOCK TABLES مورد دسترسی قرار میگیرن قفل کنید! البته برای خود من عجیب بود و تاحالا چنین چیزی رو نشنیده بودم و تاحالا مشابه چنین چیزی رو تست هم نکردم. احتمالش هست!

حالا اگر اصرار داشته باشیم که جدول دوم قفل نشه، شاید اگر کوئری مربوط به جدول دوم رو روی یک کانکشن MySQL جداگانه ارسال کنیم اونوقت دچار این محدودیت نشیم (البته باید توجه داشت که کانکشن جداگانه خودش هم بهرحال هزینه ای داره). بنده توصیه میکنم چنانچه ترافیک فوق العاده سنگین روی این جدولها ندارید و در عمل مشکلی از این بابت مشاهده نمیشه پس این ترفند رو استفاده نکنید و هر دو جدول رو قفل کنید.

ضمنا حتما میدونید که در همون یک دستور و یک کوئری LOCK TABLES میتونید چندتا جدول رو همزمان قفل کنید و نیازی به اجرای چند دستور جداگانه برای این کار ندارید.

ای ول :لبخند: همونه که بهش رسیده بودم اما همونطور که شماهم گفتین برام عجیب بود و نابهینه

بله برای قفل چند جدول در یک خط میشه

حالا پس احتمال داره همین باشه اما یک نکته ای که در stack overflow دیدم اینه که : You should use transaction for any operation which is not 1 single query!

​این طور که بوش میاد برای انجام اینجور عملیات که چندین کوئری داخل قفل قراره گرفته شه بهینه ترین حالت استفاده از ترنزکشنه بجای قفل جداولکه البته در مورد ترنزکشن نمیدونم , اگر راهنمائی کنید برای جایگذین کردن قفل هام با ترنزکشن چجوری عمل کنم ممنون میشم

eshpilen
جمعه 23 آبان 1393, 21:03 عصر
اوه بله پایین ترش هم این متن رو که خیلی روشن تر و تقریبا تمام کننده است نوشته:


It isn't permitted by MySQL to lock only one of the two tables used in the transaction above. The following rules apply to locks:

If a lock is held, all other tables that are to be used must also be locked. Failing to do so results in a MySQL error.


ترجمه: «MySQL اجازه نمیدهد که فقط یکی از دو جدول استفاده شده در ترنزکشن بالا را قفل کنیم. اگر یک قفل انجام شود، تمام جدولهای دیگری که مورد استفاده قرار خواهند گرفت نیز باید قفل شوند. عدم انجام این کار باعث یک خطای MySQL میشود.»

sahar393
جمعه 23 آبان 1393, 21:22 عصر
سلام یه سوال دارم چجوری میشه با زدن دکمه ای به صفحه جدید ولی با تب جداگانه رفت؟

eshpilen
شنبه 24 آبان 1393, 09:57 صبح
والا دیگه نه وقت دارم و نه حوصله.
آخه این قضیه رو خودمم تا این حد پیش نرفتم و اطلاع ندارم. باید تحقیق و تست و اینا کنم و دردسر داره. البته کلا مبحث مفیدیه واسه خودم هم مهمه که یاد بگیرم. ولی خب شما که دنبالش هستی میتونی در جاهایی مثل stackoverflow سوال کنی احتمال زیاد اونجا جوابهای خوب و کاملی میگیری. زبانت در این حد هست؟

intel_amd
شنبه 24 آبان 1393, 14:21 عصر
ترنزکشن که بلد بودی قبلا ها سر بحث هائی میگفتین ازش ...
اگر اینجا کسی ندونه که خوب مجبور میشم همون راه تحقیق و سایت های خارجی مثل Stack overflow پیش بگیرم دفعات زیادی اینجوری به نتیحه رسیدم اما تا اینجا بشه ترجیحم اینجاست

eshpilen
شنبه 24 آبان 1393, 14:55 عصر
ترنزکشن که بلد بودی قبلا ها سر بحث هائی میگفتین ازش ...
تا همونجا بیشتر بلد نیستم آخه :لبخند:
تازه اونم همون موقع ها تحقیق کردم یاد گرفتم واسه مطلب دادن در این زمینه. چون من خودم شغلم برنامه نویسی نیست و تاحالا ترنزکشن در عمل نیازم نشده و بیشتر از این پیش نرفتم و تست نکردم.

قدرت تئوریک باید اینطور خفن باشه یه سرنخ و نکته میاد سر راهت بگیری با قدرت تا آخرش برسی و ته و توش رو دربیاری، نه اینکه فقط موقعی که در عمل مشکل پیش میاد تازه متوجه بشی یا اینکه برای فهمیدن و حل هرچیزی نیاز زیادی به تست و تجربه و آزمون و خطا داشته باشی :چشمک:
خیلی از برنامه نویسانی که سالها برنامه نویسی میکنن این مسائل رو کشف نکردن و اینقدر قدرت تحقیق و ته توی چیزها رو درآوردن ندارن. بالاخره اینم حیطهء علاقه و فعالیت بنده بوده و توش قوی هستم.

intel_amd
شنبه 24 آبان 1393, 16:56 عصر
اوکی پس مجبورم برم ته و توشو خودم درآرم اما قبلش یک تاپیک میزنم ببینم شاید کسی روش کارکرده و نام این تاپیک به ترنزکشن ربط نداره نیمده بگه