Re: row level locking and dead-lock prevention

> Online does have deadlock detection and will abort transactions it > finds in deadlock. It doesn't have the ability to restart the > transaction. That is left upto the programmer, who may not want to > do a restart. > > In Bart's original question though the discussion is about an > automated system that must recover from a deadlock position. > Normally the easiest way to handle this is to arrange the design > so that a deadlock condition never occurs. > > Cheers - Jim > My opinions are my own. They may vary with time but they remain MINE! > ---------------------------------------------------------------------- > Name: Jim Gordon Company: DHL Systems Inc, Burlingame, CA, USA > ---------------------------------------------------------------------- > > } I'm not an expert on this, but I assume the DBMS will handle deadlock > } for you automatically - either by avoiding it or by detecting it and > } aborting and restarting the transaction. The exception would be > } if you're using Informix SE and the CISAM library. > } > } I hope somebody will confirm or deny this assumption. > } > } - Bob (rlister@megatest.com) > } > } >From article <worp.51.001736A2@knoware.nl>, by worp@knoware.nl (Bart > van der Worp): > } > Hi, informix news readers! > } > > } > We are designing a automatic message exchange system. Some > } > data is to be maitained and used; this is where informix comes in. > } > Our customer wanted us to use Informix, no choice here.... > } > > } > There are a limmited ammount of different possible transactions > } > on this database. Transactions are very short, no human interaction. > } > > } > Due to the limmited ammount of different queries and update > } > actions, it seems possible to use a locking scheme in which > } > locks for required rows are aquired in a pre-defined order. > } > Old fashioned perhaps, but save...... Another thing worth bearing in mind here is that if you've SET LOCK MODE TO WAIT n (where n is a number of seconds), you get the "deadlock" error if it times out. So in fact you may not have a *real* deadlock at all. In this case your transaction will still be active and the decision you need to make is whether to re-try the database statement, rather than the entire transaction. akent@cix.compulink.co.uk (Andy Kent) -------------------------------------