Granularity question
- From: "Dale" <dale.ng3@xxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 26 May 2005 18:32:28 GMT
I'm discussing some deadlocking issues with MSS support, and was told
something that I'm hoping is wrong.
Background info:
A classic cause for deadlocks is two connections that do the following steps
in this sequence:
Connection A gets share lock on Resource 1
Connection B gets exclusive lock on Resource 2
Connection A attempts to get share lock on Resource 2; is blocked.
Connection A attempts to get exclusive lock on Resource 1; is blocked.
Deadlock occurs.
Our problem:
We had a case where all connection A did was issue a single SELECT
statement. It was a 3 table join.
Since there was only ONE statement in the entire transaction, I was sure it
would be impossible for it to be involved in a deadlock; either it would be
blocked and wait for the other connection, or it would go through and any
other connections would have to wait.
The support person said that the select statement could have gotten some of
the required share locks, but not been able to finish getting all of them,
and that's why the deadlock occurred.
For example, Connection A got share locks on rows/pages 1 and 2, then
connection B got some locks, then Connection A tried but failed to get the
remaining locks.
I would have thought that MSS would grant all locks required for a single
statement at once, and not allow other connections to get in the middle of
this.
Anyone know what the case really is? Thanks.
Dale
.
- Prev by Date: Re: A silly question
- Next by Date: sql server set wrong
- Previous by thread: A silly question
- Next by thread: sql server set wrong
- Index(es):
Relevant Pages
|