Hi,
On 2001.06.26 11:24:43 -0400 Georg Rehfeld wrote:
<snip>
> But maybe Bill is right, OL could be used with commit option A
> and single bean instances too? I'm not really sure ... no I
> don't think so, because then every TX is working on state
> possibly modified by another TX and, even worse, with one
> instance only the optimistic approach (based on the diff of the
> actual beans state and the state before TX.begin) will fail, as
> at commit time the 'old' state has to be set equal to the current
> state and the next concurrent TX committing will succeed, where
> it should see a 'you are too late to commit' exception!
>
I don't think I understand what you are suggesting. However...
Are you familiar with the lock-free versioning/ optimistic locking scheme
used in interbase/firebird?
transactions are numbered sequentially when they are started.
Each record (version) includes the transaction id of the last change to it.
When you query information (within a transaction), you get the record
version with the largest transaction id <= your transaction id.
When you change a record, a new version is put in the db with your
transaction id ( of course no one else can see it till you commit). The
older versions hang around until no transactions are active that could see
them, then they are garbage collected.
There is a transaction property that determines behavior when two
transactions try to modify the same record: 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 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.
I think you could use a scheme like this at least with commit option A.
david jencks
> 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
