Re: oracle timesten

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:

1. create table with single column (for example) without indexes and fill it with 2 rows with different values
2. in session#1 update the first (yep, i know about order by :o) inserted row, do not commit
3. 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

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