Re: The twin problem (was Re: HELP - Index Locks are creating DEADLOCKS)

In article <1992Nov11.203538.29976@informix.com> cortesi@informix.com (David Cortesi) writes: > >The method used is to place a lock on the next higher index entry, >and to require any transaction that would insert a value to >acquire a lock on the adjacent key. This ensures that no other >process can insert the original key until the first transaction >completes. > >There is no basic difference between a lock conflict based on the twin >problem and one caused by two processes trying to update the same row. >Both result from two processes attempting to seize the same resource at >the same time. > >Is this not so? > >Dave Cortesi > cortesi@informix.com While the may be no 'basic difference' in low level INFORMIX code between a lock on a row and a lock on an adjacent index key, there is a VERY BIG DIFFERENCE at the user level, when several users are trying to update a database, and their updates fail due to adjacent key locks, rather than row locks. We designed our application using row level locking for data integrity. The very poorly (if at all) documented issue of adjacent key locking has confused and frustrated our users, since they think they will not see locking problems if they are not updating the same row as someone else. It would be of some help to describe what 'adjacent keys' are. Dave, can you post a description of adjacent keys, or point to a definition in INFORMIX documentation (not Tech Notes; I have been unable to get back copies from INFORMIX).