Re: adjacent key locking

We are having a similar problems :- online 7.12 isolation level is dirty read lock mode is row level set wait is 5 A large(ish) process is inserting into the table in question, as soon as someone tries to update this table via a composite primary index they often get timed out (sql -243 isam 154), how can this happen if we're using the above settings. My immediate work around is to increase the wait to 10 ( obviously far too long). I will start analysing the application in more detail to reduce the unit of work, but is strikes me that there is still an adjacent key locking problem in this scenario. Any views ? Richard Stanford <richards@herald.net.REMOVE> wrote in article <Pine.BSF.3.91.970605131249.13082C-100000@kilimanjaro.dallas.herald.net>... > On 5 Jun 1997, Nicholas Allon wrote: > > > Could anyone please explain the problem of adjacent key locking when it > > occurs and any possible solutions. The informix error code was -243. We are > > using AIX 3.5, with informix online 7.12 > > What makes you think that this is adjacent row locking? > > Adjacent row locking, apart from being old news (fixed by 5.05 and 7.v.early I > believe) was the condition where the engine would lock the row after a row > being inserted, in case you were about to insert another one. This is a badly > worded example, but its one of those days -- correct me if I'm wrong[0]. > > What's more likely is that some other process was locking the data that you > were attempting to select/modify/whatever. > > Are you set to lock mode row? If not, then you may have ran into another > problem where processes accessing physically-close data can have you locked. > > The majority of locking problems may be fixed with the careful application > of a SET LOCK MODE TO WAIT 1 statement to the top of the code. You can > increase the 1 upwards (its in seconds) but even a 1 will retry numerous times, > and eliminates most of the momentary-lock type problems. > > -Richard > > [0] Not that I'd expect people not to if I did'nt ask them to... >