Hi,
Bill:
> |- Somebody had a great idea earlier of adding "optimistic locking" for
> |CMP/JAWS. Along with this feature, you could write a specialized
> |EntityInstanceInterceptor that did not do "transactional locking" with
> |commit Option 'A'. This would be great for beans that had
> |read-only invoked operations 90% of the time.
I suggested that and did take the job implementing it (though I actually
did no coding yet because I have to earn some money).
Marc:
> yes, that would be interesting, BUT AGAIN I WANT TO FINISH OFF THE 2.X
> SERIES WITH THE BUGS REMOVED and the streamlined cache with transactional
> locking.
> ...
> WE NEED STABILITY IN FEATURES
Yes, agreed.
My suggestion was intended for the Rabbit Hole and originally
meant to be used with commit options B/C in case there are
multiple bean instances when Rabbit Hole is finished.
Multiple instances would be not very usefull with pessimistic
locking done on the DB, as the pessimistic behaviour (and locking
waiting without a message) simply would remain viewed from the
clients perspective.
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!
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
