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
