Hi, the algorithm is in the post marc was replying to.
Here it is again, with garbage collection instructions and referring to
entities rather than records.
transactions are numbered sequentially when they are started.
Each entity (version) includes the transaction id of the last change to it.
When an entity is first loaded from the db, the transaction id of the
transaction in which it is loaded is associated with the entity version.
When you find an entity (within a transaction), you get the entity
version with the largest transaction id <= your transaction id.
When you change an entity, a new version is put in the cache with your
transaction id ( of course no one else can see it till you commit: the
entity versions need both the transaction sequence and some way of telling
if they are committed.). The
older versions hang around until no transactions are active that could see
them, then they are garbage collected. (see below)
There is a transaction property that determines behavior when two
transactions try to modify the same entity: either
you get an immediate exception
or
your changes block until the other guy commits (you get an exception) or
rolls back (your transaction succeeds)
Note that only the most recent (committed) version can be modified by any
transaction, and that the blocking/ exception behavior just described only
applies to 2 transactions trying to modify the most recent committed
version.
Each transaction as it starts is put on an ordered (by transaction
sequence) list of active transactions. When it is committed or rolled
back, it is removed. The first transaction on this list is the oldest
active transaction.
The transaction associated with the oldest entity version we have to keep
around is the oldest interesting transaction.
Lets suppose we have an entity with versions for transactions t1, t7,
t11,...
We can discard the version for t1 when the oldest active transaction is at
least t7, because all transactions that could possibly reference that
version have completed.
Note that this results in snapshot transaction isolation rather than read
committed. (I don't know how read committed is implemented, and don't know
why you would want to use it). I confess I don't quite understand how
snapshot differs from serializable isolation -- its certainly close.
This requires a version for each modifying transaction, rather than a
single version or a version for each transaction. You may need to keep
several committed versions around at once until all transactions
referencing them are complete.
Interbase versioning is per transaction , not per query.
Please ask if this is not clear.
david jencks
On 2001.06.26 18:47:17 -0400 Georg Rehfeld wrote:
> Hi,
>
> David Jencks wrote:
>
> > Yes, I was trying to point out that interbase/firebird has been
> > doing this successfully for 15 years, we can have our container
> > do it too, here's an algorithm
>
> you left out the most interesting: the algorithm! Please forward!
>
> > Someone mentioned that there "might" be dbs using optimistic
> > locking: interbase/firebird is one such.
>
> :-)
>
> > As an aside, this versioning idea of Jim Starkey is the reason
> > interbase/firebird exists. It allows a production database to
> > generate meaningful reports: the report runs in a transaction
> > that only sees the data present when the report started, yet
> > production transactions can freely modify all the data in the db
> > without affecting the report.
>
> This is the same with Oracle (one reason Oracle exists and still
> is one of the marked leaders :-). Note, that I'm not affiliated
> with Oracle in any way. Just used it the last 13 years (and other
> DBs as well, went back to Oracle most of the time).
>
> Oracle calls this 'read consistency' and at the lowest possible
> level only reads committed data and returns only data as of the
> time the query started, even when the read would need hours to
> complete and without hindering any other TX to update freely
> (including deleting ALL rows from the table). At that lowest
> level, this is not repeatable, the next same query then sees the
> data as of the new query start time, but there is a setting to do
> it repeatabe (which then USES locks, whereas the default
> behaviour is lock free).
>
> regards
> Georg
> ___ ___
> | + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
> |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
