Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Problems explaining deadlock chain


Problems explaining deadlock chain

Author
Message
Kaushik Majumder
Kaushik Majumder
Valued Member
Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)

Group: General Forum Members
Points: 65 Visits: 786
Hi,

We are currently in a spot of bother, attempting to explain a deadlock chain and would really really appreciate any guidance/help in explaining what exactly happening and possible ways to mitigate please.

Here's a brief overview of the scenario.

There is one SP 'sp_Select_ActionsForProcessing' that is invoked at the same time by multiple threads. The SP selects a range of qualified records and selects the top 1 qualifying record. When the second thread runs, it will select the qualifying range excluding the one selected by the first one and so forth. We implemented the same with UPDATELOCK HOLDLOCK table hint, However, we do suspect the same to be the cause of contention, but could not pinpoint.

Will appreciate any help please.

Attached is the .xdl file, .xml and proc text.
Attachments
Deadlock Chain.zip (9 views, 6.00 KB)
Erland Sommarskog
Erland Sommarskog
SSC Eights!
SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)

Group: General Forum Members
Points: 931 Visits: 866
I think you shold take out the HOLDLOCK. HOLDLOCK is the same as SERIALIZABLE, that is protection against "phantom reads", that is rows that were inserted since you read the range. Since your procedure is not inserting any rows, I don't see you need it.

The serializable isolation level is quite prone to deadlocks, so avoid it if possible.

Erland Sommarskog, SQL Server MVP, www.sommarskog.se
Kaushik Majumder
Kaushik Majumder
Valued Member
Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)

Group: General Forum Members
Points: 65 Visits: 786
Thanks a lot for your insight. We also believed in the same way, specifically, the victim's request on the resource was for an update lock.

We were and still are a bit baffled with interpreting the deadlock chain. If you did manage to have a look at the .xdl file, in one chain, it is shown, one process has been granted exclusive lock, however, in the chain involving deadlock, another process has been granted Update lock on the same keyid.

Thanks and regards.
Erland Sommarskog
Erland Sommarskog
SSC Eights!
SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)

Group: General Forum Members
Points: 931 Visits: 866
I will have to admit that I did not look at the deadlock chain. My experience of serializable was enough.

Erland Sommarskog, SQL Server MVP, www.sommarskog.se
Kaushik Majumder
Kaushik Majumder
Valued Member
Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)

Group: General Forum Members
Points: 65 Visits: 786
Apology for being late in getting back. You were quite correct. Getting rid of the HOLDLOCK solve the issue, however, teh DEADLOCK took other SPs as preferred partner. Smile

I did suggest to try with READ_COMMITTED_SNAPSHOT isolation level as the default isolation behavior, but the technical architects are a bit jittery as it will make the tempdb to take the toll. We have implemented the TRY..CATCH method for troubleshooting. Please advise if this is a correct approach.


Regards.
Erland Sommarskog
Erland Sommarskog
SSC Eights!
SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)

Group: General Forum Members
Points: 931 Visits: 866
READ_COMMITTED_SNAPSHOT is an excellent idea, but it will not apply in this case, as UPDLOCK implies REPEATABLE READ.

Erland Sommarskog, SQL Server MVP, www.sommarskog.se
Stefan_G
Stefan_G
Old Hand
Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)

Group: General Forum Members
Points: 337 Visits: 953
In these cases with complicated code that takes different kinds of locks and you have problems with deadlocks it might be a good idea to explicitly take an application lock at the beginning of each stored procedure that manipulates these tables.

Like this:


BEGIN TRAN
exec sp_getapplock 'MyRersourceName', 'Exclusive'

-- Application code
..
COMMIT



Of course this might lower the concurrency so it could lower the performance but at least you will not have to worry about deadlocks.

The lock taken by sp_getapplock when called in this way is always held until the end of the transaction.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search