Re: How to handle deadlocks ?

In <4pi4u1$5i_at_chleuasme.francenet.fr> cberthet_at_MicroNet.fr (Christophe Girard-Berthet) writes:
>
>In article <DsszAL.7MC_at_world.std.com>, bgw_at_world.std.com (Bruce G
 Wilson) says:
>>
>>
>>I've been on a couple of contracting jobs where the client uses
>>Sybase (4.9 and System 10). At each place, there were occasions
>>where they had problems with deadlock: two processes trying to
>>allocate two resources in opposite order. It struck me that part
>>of the reason why this is such a problem is that locks are taken
>>(and escalated) implicitly in Sybase, so that it's difficult from
>>a superficial read of the code to tell when a lock is being taken
>>and where the conflict might be occurring. I guess I'm kind of
>>surprised to find that locks can't be taken explicitly; with this,
>>it would be made clear in the code where the locks are being taken
>>and might make it easier to determine where the problem is.
>>
>>I'm wondering, what kinds of techniques are used in "standard"
>>practice with Sybase to detect/prevent deadlocks ? Do IS
>>organizations establish rules for accessing the database, like,
>>"always do an update to table A before doing an update to table B" ?
>>It strikes me that that's really the only way to control this
>>sort of problem.
>>
>>I can't imagine that other databases (Oracle, Informix) don't also
>>have this kind of problem. How are deadlocks handled in these ?
>>
>
>Ordering access to the objects in your database is the best way
>to REDUCE dealock, keep transactions as short as possible too.

Some large sites have thrown hardware at the problem. There was an article in ComputerWorld 'bout 2 years ago on this very subject. It seemed that going to faster I/O ("keeping the transactions as short as possible") made a world of difference.

Robert David _at_ Imperial Technology Received on Tue Jun 18 1996 - 00:00:00 CEST