Re: ADJACENT KEY LOCKING

In article <43359s$fbd@nezsdc.fujitsu.co.nz>, steve@nezsdc.fujitsu.co.nz (Steve Chell) says: > > >I'm trying to understand how adjacent key locking works, but my test >results don't agree with the ENGREL_5.0 documentation, nor the FAQ >located at http://ww.garpac.com/informix.html. The way that I try to convince myself this works is as follows; When a delete happens, and it is not yet comitted, the database has to prevent anyone else inserting a key of the same value. Since the deleted key is no longer there, it locks the next highest value, or, if there is no next highest value, it locks the 'infinity' value. When an insert is attempted, the insert process checks the next highest value to see if it is locked, and fails if it is. This seems to be what actually happens. In your example, you would not have hit this type of lock because you did no deletes, so no adjacent keys would be locked (it only happens following a delete). On an insert, only a check is done to see if the adjacent key is locked, but no adjacent key locking happens, it is not needed. The actual row inserted is locked instead. You can watch all this going on if you use tbstat -k Hope this helps Tony Tyrwhitt-Drake