Andrey, oh, interesting - looks like some kind of read lock, possibly a shared read lock: readers don't block readers readers block writers writers block readers writers block writers (of course!) ... am I correct ? So back to your test: a) create table with single column (for example) without indexes and fill it with 2 rows with different values b) in session#1 update the first (yep, i know about order by :o) inserted row, do not commit c) try to update the second row in session#2 - session is blocked if session#1 needs to read the second row in(b), it locks it, thus preventing session#2 from updating. With an index - it may follow the index and jump directly to the first row, avoiding the read on the second row - thus not "locking" it. -- Just an idea - I have an interest in TT but I haven't found the time to investigate it (yet) - surely some results about the locking model of TT would be an incentive for investigation :) On 11/21/06, Andrey Kriushin <Andrey.Kriushin@xxxxxxxx> wrote:
Alberto, this is not lock escalation. Definitely. We've checked, that there are row locks by rowid. Also I doubt if there is a notion of "block" in TT (not sure though). Of course we've checked that. Also if one uses unique index/primary key to update single row, the sessions are not blocking each other. What we've seen is that when a session accesses the row just in order to _*check*_ if the row satisfies the selection criteria, this check is being done with some kind of row lock. I.e. for locked row the lock mode is Xn - Exclusive lock for non-serializable isolation. While checking, the lock mode wanted is Un - An update lock for non-serializable isolation.
-- Alberto Dell'Era "Per aspera ad astra" -- //www.freelists.org/webpage/oracle-l