Adjacent Key Locking!!
tknoefel@yahoo.de wrote: > > Hi, > Has somebody heard something about Adjacent Key Locking??? > > If you have isolation level repeatable read and selecting, deleting or > updating an indexed table (row locking) than the next row will also be > locked. Does anybody know the reason for that or where I can find > information about that? > > Thanks > Thomas Repeatable read is an isolation level in IDS thats purpose is to "guarantee" the data that has been read by a session will not change until the session has finished with its cursor. If I read customer numbers 104 and 106 (in a row) (say customer_num > 104), and another user tries to insert customer 105, that would change my result set -- so the adjacent key is held to prevent this from happening. Can you choose another isolation level in your application? -- there are others that are less agressive -- assuming you are not worried about the data changing. The default is committed read for non-ansi databases, and repeatable read for ansi databases. You can learn more about this subject by checking your Informix Documentation -- in particular, the SQL Tutorial has a nice discussion about isolation levels, locking, etc. Good luck J.
Hi, Has somebody heard something about Adjacent Key Locking??? If you have isolation level repeatable read and selecting, deleting or updating an indexed table (row locking) than the next row will also be locked. Does anybody know the reason for that or where I can find information about that? Thanks Thomas
tknoefel@yahoo.de wrote: > > Hi, > Has somebody heard something about Adjacent Key Locking??? > > If you have isolation level repeatable read and selecting, deleting or > updating an indexed table (row locking) than the next row will also be > locked. Does anybody know the reason for that or where I can find > information about that? It's in the Manuals?!?! Actually the next row is not locked it is the adjacent index key that is locked in case the update, and certainly the delete will, modifies the key and so would have to delete the entry there and create a new one. Since the transaction could be rolled back the next key entry to the original index key is locked. The details of why are in the manual. Art S. Kagel