Re: Let me be the first
Obnoxio The Clown wrote: > Lukas Barton said: > >> It does not, because Informix locks also previous and next row in all >> indexes. So that the probability of locking rows that other user want to >> read is more than zero. >> > > I'm fascinated by this assertion. I guess I've just been unbelievably > lucky all my working life. > See - http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/com.ibm.perf.doc/perf104.htm?resultof=%22%72%6f%77%22%20%22%6c%6f%63%6b%22%20%22%69%6e%64%65%78%22%20 (2 per changed key value) - http://docs.rinet.ru/InforSmes/ch15/ch15.htm ( For an index, three more locks are necessary--one lock for the accessed row, one for the row before the accessed row, and one for the row after the accessed row)
> - > http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/com.ibm.perf.doc/perf104.htm?resultof=%22%72%6f%77%22%20%22%6c%6f%63%6b%22%20%22%69%6e%64%65%78%22%20 > (2 per changed key value) > update locks.. 1 lock required for an update on the row 2 required on the key if you are updating the key so you are updating the key?
scottishpoet wrote: > update locks.. > > 1 lock required for an update on the row > > 2 required on the key if you are updating the key > > so you are updating the key? > > > Yep. I update indexed column.
Lukas Barton wrote: > Obnoxio The Clown wrote: >> Lukas Barton said: >> >>> It does not, because Informix locks also previous and next row in all >>> indexes. So that the probability of locking rows that other user want to >>> read is more than zero. >>> >> >> I'm fascinated by this assertion. I guess I've just been unbelievably >> lucky all my working life. >> > See > - > http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/com.ibm.perf.doc/perf104.htm?resultof=%22%72%6f%77%22%20%22%6c%6f%63%6b%22%20%22%69%6e%64%65%78%22%20 > (2 per changed key value) Lukas. When you change an index key value, you need a lock for the before copy to protect the prior key entry in the index. Otherwise, you could not roll back. Also, you need a lock for the after image - otherwise someone else could make the same change before you commit. These are not adjacent key locks which went away with version 5. It does NOT lock the previous and the next row. Index locks are not done so much by locking a row. It is more like locking a value. > > - http://docs.rinet.ru/InforSmes/ch15/ch15.htm ( For an index, three > more locks are necessary--one lock for the accessed row, one for the row > before the accessed row, and one for the row after the accessed row) This information is invalid since v6. With v5, we had something called adjacent key locking which was used to prevent someone from inserting an index item until the transaction which may have deleted that item had issued a commit. We changed that logic with version 6 with the addition of a 'delete' flag as part of the index item. That's what the b-tree cleaner is all about. We no longer lock the adjacent key. > >
> > This information is invalid since v6. With v5, we had something > called adjacent key locking which was used to prevent someone from > inserting an index item until the transaction which may have deleted > that item had issued a commit. We changed that logic with version 6 > with the addition of a 'delete' flag as part of the index item. > That's what the b-tree cleaner is all about. We no longer lock the > adjacent key. > Thanks for explaining me the problem. You gave me first veritable advice on this problem. Is that key locked for reading or only for updates? Lukas > >> >> > >