Re: oracle timesten

  • From: "Alberto Dell'Era" <alberto.dellera@xxxxxxxxx>
  • To: Andrey.Kriushin@xxxxxxxx
  • Date: Tue, 21 Nov 2006 20:24:39 +0100

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


Other related posts: