Re: How to handle deadlocks ?
Date: 1996/06/12
Message-ID: <4pne35$rc1_at_abacus.tis.tandy.com>#1/1
>>If you follow a fixed locking order you can avoid most deadlock
situations.
>>Whether locks are taken implicitly or explicitly doesn't make any
difference,
>>as long as the database designer *knows* how the RDMBS locks resources.
>>
>[snip]
>Not really, and only if you employ full table level locks on data. If you
are
>locking at the row or page level, you need to specify locking orders at the
>row/page level to avoid deadlocks. Problem is, you can't specify locking at
the
>row or page level in any system.
>
Maybe I'm confused on this response. We use order of tables to handle
deadlocks across several different databases (Oracle, NonStop, Rdb). Now
some databases don't support exclusive locks, but ones that do can at lest
minimize deadlocks. If a db supports row level locking, you should be able
to eliminate deadlocks.
Here I should probably define a deadlock. User 1 gets a lock on row A and simultaneously User 2 gets a lock on row B. User 1 then trys to get a lock on row B and User 2 tries to get a lock on row B. As is apparent, this kind of deadlock is caused by a problem of locking order. To solve the problem, lock the rows in the same order. A real world example is to lock an order header row before you make any changes to the order. This would prevent different processes that update parts of the order (typically across multiple tables) from trying to update the parts of the order in a different sequence, thus eliminating the deadlock.
Geoffrey Bray | Standard disclaimer Tandy Information Services | gbray1_at_tandy.com | ------------------------------------------------------------------------------Better to be silent and thought a fool than to open your mouth and remove all doubt!!!
Received on Wed Jun 12 1996 - 00:00:00 CEST