Re: oracle timesten

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.

--Andrey
PS. Address your thanks to my colleague Alexey Zolotarev who will probably join the list soon :-)

Alberto Dell'Era wrote:
> This looks like lock escalation to the "block" level,
> (or simply lock granularity = block), not write consistency ?
>
> Interesting fact either way, thanks for pointing it out :)
>
>> A simplest 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
>>
>> We've also played with a "range scan" of nonunique indexed column of
>> two-column table, just to be sure that there is nothing special in "FULL
>> SCAN".

--
http://www.freelists.org/webpage/oracle-l