Re: Online bug? Tech Support clam it isn't

In article <34DF664D.3112@informix.com>, June Tong <junet@informix.com> writes >Peter Tashkoff wrote: >> >> It is not a bug. > >This is true. > >> You need the index to navigate the table. If you have no index each row = >> must be tested in a sequential read to see whether it meets the criteria = >> for update. The first thing that Online does is to place a lock on the = >> row, for the committed read. Since you are operating within a singleton = >> transaction this lock will not be released until your transaction is = >> committed. Not only is this 'Just the way it works', it is IMO, sound = >> design. > >Actually, Committed Read does not place locks. It only TESTS for >existing >locks. Committed Read will not lock anything, but it will bomb out if >someone else has your row locked. > >What Peter says here is true for Repeatable Read isolation level. > >> >>> Dave Cook <dave.cook@excelsis.co.uk> 7/02/98 06:10:29 >>> >> >> Any opinions on whether the following is a bug? Tech Support tell me it >> isn't as it's "just the way it works". >> >> When performing an update, a lock is placed on all rows scanned in the >> table, unless the update statement uses a unique index Sorry guys! I made a crucial omission from my original posting. The table is created with 'lock mode row' and I also set the isolation level to 'dirty read'. Thanks -- Dave Cook