|Hm.. don't quite understand the above.. no change needed I think: just
|mandate that commit option C is used, and that should be all.
hold on a second... let me make sure we talk about the same thing.
Ok so we are discussing "optimistic" caches and Tx management.
Basically what I found "off target" in Dan's mail is that the container
today is designed for pessimistic control at the container layer. In other
words, the container implementation doesn't permit what he is talking about
but the interface has little value (and in fact is kosher per my last mail).
so how would we do it? I assume for now we are looking for a way to have
*several* instances in a server involved in different transactions but
reflecting the same identity in the database.
To be very honest the above sentence doesn't make much sense to me. The
pattern from theserverside where you keep a index of the "update" that can
make sure you have concurrent (and long running) transactions on the same
entity, would be a way to do it properly. So now if we have several
entities reflecting the same identity but in different transactions I would
assume that *all rw updates but one* will fail, so having the several
transactions in the first place is just for "read-only", otherwise the rw
stuff is equivalent to what we have today (and at least our stuff doesn't
throw exceptions allover the place).
So what does Option C buys us? when we start the transaction we do load the
state from the database... woohoo, well yes, since the state is non-valid,
however we still have the same problem I just described, which is that the
state loaded is potentially invalid as soon as loading is done. For it not
to be the case we need to lock the db or use the pattern above.
In clear opC is "band-aid", the key is in lock management in distributed
objects, we should read the research there, so little time ...
Maybe I am missing something?
marc
|/Rickard
|
|--
|Rickard �berg
|
|Email: [EMAIL PROTECTED]
|http://www.telkel.com
|http://www.jboss.org
|http://www.dreambean.com
|
|
