Re: oracle timesten
- From: Andrey Kriushin <Andrey.Kriushin@xxxxxxxx>
- To: john.kanagaraj@xxxxxxxxx
- Date: Tue, 21 Nov 2006 04:15:24 +0300
Hi,
John Kanagaraj wrote:
Personally, it works best for situations where your application is
query intensive with small updates.
Actually, we are new to TT, and today a colleague of mine was playing
with updates. What we've noticed is that there is not such thing as
consistent gets in "select phase" of update. I mean an analogue of
"write consistency" mechanism as explained by Tom Kyte here:
http://asktom.oracle.com/%7Etkyte/wc.html
http://tkyte.blogspot.com/2005/08/something-different-part-i-of-iii.html
For those who don't like to go into much details: Write Consistency in
Oracle RDBMS means that during the first pass (of update, delete, merge)
a set of rows is formed via consistent reads (non-blocking and
unblockable {don't confuse with unbreakable}), which is then locked via
current reads.
That lead us to conclusion that TT uses pessimistic locking on updates.
More precisely, unlike Oracle RDBMS, TT immediately performs current get
on update. Not checked for delete yet, but don't see why it should be
different.
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".
Welcome to pessimistic world of TimesTen, guys! What kind of the
database is TT then? Half Versioned Semi-Blocker? Well, probably it is
not that bad as it appeares. But be prepared.
--Andrey
--
//www.freelists.org/webpage/oracle-l
Other related posts:
