November 19, 2012 at 3:14 pm
Hello,
For this scenario :
update Table1 with (TABLOCK, XLOCK)
...
then a "INSTEAD OF TRIGGER" on Table1 update Table1 with other value
Does the trigger keep the initial (TABLOCK, XLOCK) or the lock is released and another one is made for the trigger?
Thanks
November 19, 2012 at 10:59 pm
hi2u (11/19/2012)
Does the trigger keep the initial (TABLOCK, XLOCK) or the lock is released and another one is made for the trigger?Thanks
Yes to maintain the atomicity there will be seperate LOCK
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
November 20, 2012 at 8:00 am
Thank you for the info
November 20, 2012 at 8:38 am
Bhuvnesh (11/19/2012)
hi2u (11/19/2012)
Does the trigger keep the initial (TABLOCK, XLOCK) or the lock is released and another one is made for the trigger?ThanksYes to maintain the atomicity there will be seperate LOCK
What do you mean "by separate LOCK"?
Intial locks placed on a table for UPDATE will be there until transaction is committed. INSTEAD OF trigger fires before SQL performs any change (not even change logging), so the only thing I can see may happen is LOCK escalation to the higher level...
November 20, 2012 at 9:10 am
hi2u (11/19/2012)
Hello,For this scenario :
update Table1 with (TABLOCK, XLOCK)
...
then a "INSTEAD OF TRIGGER" on Table1 update Table1 with other value
Does the trigger keep the initial (TABLOCK, XLOCK) or the lock is released and another one is made for the trigger?
The exclusive table lock will be held until the end of the execution of the trigger.
Triggers execute within the transactions that fire them, exclusive locks are held until the end of the transaction, hence that lock will be held for the duration of the trigger's execution.
btw, you could have just used the TABLOCKX hint, that does the same as those two combined.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
November 20, 2012 at 10:44 am
Thank you for the clarification
GilaMonster (11/20/2012)
btw, you could have just used the TABLOCKX hint, that does the same as those two combined.
This thread showed me that i should not trust every forum post but i always thought this was not true because of this :
http://dbaspot.com/ms-sqlserver/140553-transaction-deadlock-tablelocks.html
November 20, 2012 at 11:19 am
hi2u (11/20/2012)
t i always thought this was not true because of this : http://dbaspot.com/ms-sqlserver/140553-transaction-deadlock-tablelocks.html
That thread's talking about SELECT and the locks it takes. You're talking about UPDATE. Very different locking behaviour in the default isolation level.
In read committed isolation (the default), shared locks taken by selects are released as soon as the statement completes (sometimes earlier), while the exclusive locks taken by insert, update and delete are held until the end of the transaction.
And yeah, unfortunately not everything posted in the forums is true. You have to consider the poster's history and check more than one source to be sure (or test if it's something testable).
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
November 20, 2012 at 11:27 am
well i learned something today.
Thank you !
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply