> |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).
Yes, an OptimisticKey would work. (I think, will have to actually do it to
be sure)
> 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.
Correct, as outlined in the EJB spec.
> To be very honest the above sentence doesn't make much sense to me.
It does to me and a whole lot of people (especially judging from the
comments made at the J2EE retreat I attended awhile ago).
> 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.
No, that is completely different.
> 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,
Correct, and the assumption is that one has read-mostly.
The two basic rationales (AFAIK) for optimistic is to:
* avoid deadlocks (never deadlock, only rollback on conflicts)
* remove contention
> 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).
Incorrect. It is for read-mostly, and gives the two features outlined above.
AFAICT these are very important features for a lot of people.
> 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.
Incorrect. State is valid for the duration of the transaction, which is why
option C is necessary (option B could work too, but then you'd need to
change the interface as outlined by Dan). You need to read up on locking
schemes and isolation levels.
> 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?
Yes, you are, but it's a somewhat long story to write in an email I'm
afraid. I recommend reading the Database Fundamentals, especially on locking
and tx isolation. I don't think anything short of that will give you a clear
picture of why this is necessary for a lot of cases.
regards,
Rickard
