Re: How to handle deadlocks ?

pao_at_ai.mit.edu (Patrick A. O'Donnell) wrote:
>In article <4q4tap$hum_at_dfw-ixnews7.ix.netcom.com> enelson3_at_ix.netcom.com(Eric D Nelson) writes:
> Date: 18 Jun 1996 00:30:17 GMT
> From: enelson3_at_ix.netcom.com(Eric D Nelson)
>
> I have also encountered deadlocks while doing a select. I didn't think
> this would be possible.
>
>I, too, though deadlocks from a select shouldn't happen. Once I saw
>it, however, I realized that it was easy: the select acquires shared
>locks, which could be acquired in a different order from an updater's
>exclusive locks --- deadlock. It is still true that readers should
>never deadlock against each other.
>
> - Pat
I'll add one more bit of information. The victim of a deadlock can be the process inserting, updating or deleting and the victor the select process! I've seen this when a 3rd party application had a long batch program that suddenly stopped with no message.

BTW, a good way to be aware of deadlocks is with auditing of system 10 and system 11. It can also have info written to the errorlog with trace flag 1204.

Bob Munson

-- 
"time(stamp) is money"
_at_Str=convert(varchar(21),convert(numeric(19,4),convert(money,timestamp)))
Update... Where tsequal(timestamp,convert(varbinary(8),convert(money,
          convert(numeric(19,4),_at_Str))))