View Full Version : قفل نشدن جدول!!!
hooooman
چهارشنبه 04 اردیبهشت 1387, 01:31 صبح
سلام
من توی دیتابیسم به 1 جدول select میزنم:
begin transaction
select * from List with (xlock,holdlock)
حالا عجیب اینجاس که وقتی توی 1 QA دیگه 1 select دیگه میزنم باز نتیجه رو نشون میده انگار هیچ قفلی روش نیست!!!!
select * from List
چرا؟؟؟!!!!!!!
Kamyar.Kimiyabeigi
چهارشنبه 04 اردیبهشت 1387, 08:00 صبح
* FASTFIRSTROW—The query is optimized to get the first row of the result set.
* HOLDLOCK—Hold a shared lock until the transaction has been completed.
* NOLOCK—Do not issue shared locks or recognize exclusive locks. This may result in data being returned that has been rolled back or has not been committed; therefore, working with dirty data is possible. This may only be used with the SELECT statement.
* PAGLOCK—Locks the table.
* READCOMMITTED—Read only data from transactions that have been committed. This is SQL Server's default behavior.
* READPAST—Rows locked by other processes are skipped, so the returned data may be missing rows. This may only be used with the SELECT statement.
* READUNCOMMITTED—Equivalent to NOLOCK.
* REPEATABLEREAD—Locks are placed on all data used in queries. This prevents other users from updating the data, but new phantom rows can be inserted into the data set by another user and are included in later reads in the current transaction.
* ROWLOCK—Locks the data at row level. SQL Server often locks at the page or table level to modify a row, so developers often override this setting when working with single rows.
* SERIALIZABLE—Equivalent to HOLDLOCK.
* TABLOCK—Lock at the table level. You may want to use this when performing many operations on table-level data.
* UPDLOCK—Use update locks instead of shared locks while reading a table, and hold locks until the end of the transaction. This has the advantage of allowing you to read data without locking and to update that data later knowing the data has not changed.
* XLOCK—Uses an exclusive lock on all resources until the end of the transaction.
مطالب بالا رو ازلینک زیر گرفتم
http://articles.techrepublic.com.com/5100-6329-5181472-2.html
AminSobati
چهارشنبه 04 اردیبهشت 1387, 10:10 صبح
دوست عزیزم،
SQL Server برای افزایش همزمانی کاربرها، زمانی که میتونه اطمینان حاصل کنه که نتیجه Query صحیح خواهد بود، از Block کردن کاربر Select کننده اجتناب میکنه. این کار، یک مکانیزم برای بهینه سازی Concurrency تلقی میشه.
اگر شما در جدول خودتون یک ویرایش ساه انجام بدین، از حالا به بعد کاربری که Select میکنه قطعا Block خواهد شد. اگر نیاز دارید الزاما کاربر در هر حالتی Block بشه، در Query اولی از XLOCK, PAGLOCK استفاده کنید.
hooooman
چهارشنبه 04 اردیبهشت 1387, 15:36 عصر
دوست عزیزم،
SQL Server برای افزایش همزمانی کاربرها، زمانی که میتونه اطمینان حاصل کنه که نتیجه Query صحیح خواهد بود، از Block کردن کاربر Select کننده اجتناب میکنه. این کار، یک مکانیزم برای بهینه سازی Concurrency تلقی میشه.
اگر شما در جدول خودتون یک ویرایش ساه انجام بدین، از حالا به بعد کاربری که Select میکنه قطعا Block خواهد شد. اگر نیاز دارید الزاما کاربر در هر حالتی Block بشه، در Query اولی از XLOCK, PAGLOCK استفاده کنید.
جناب ثباتی من از شما چیزهای زیادی یاد گرفتم و از لطفتون خیلی ممنونم
vBulletin® v4.2.5, Copyright ©2000-1404, Jelsoft Enterprises Ltd.