Re: oracle timesten

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_at_rdtex.ru> 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"
--
http://www.freelists.org/webpage/oracle-l