|This might be a stupid question, but I'll ask anyway. It seems that
|the InstanceCache interface, which gets EnterpriseContexts based
|on the primary key of the bean, forestalls the possibility of using
|Commit Option C and deferring concurrency control to the
|database. Wouldn't you need to add the current transaction to
|interface methods such as:
|
| public EnterpriseContext get(Object id)
| throws RemoteException, NoSuchObjectException;
|
|Otherwise how could you have two instances of the same object
|existing concurrently in different transactions? With this interface,
|it seems as if concurrency control would always be done by the
|container. Maybe this is handled implicitly (or more likely I'm
|missing something)...
Ok you are saying that
Optimistic caching <-> opKey = (pk + tx-id)
and
Pessimistic caching <- pesKey = pk
which is right.
however the interface doesn't *preclude* the first statement, as implicit
look up of the tx associated could be possible and so we build opKey in
cache layers, but you know me, anything explicit is better and fast! so when
we go that way, passing the tx to the cache is cleaner (your analysis is
right, I disagree with the "forestalls").
All this is saying is that opKey is UNIQUE so there is not even a "duplicate
involved" it is seen as a "new instance" by the cache... this is trivial to
do.
One thing I believe we would need to change is that we commit the state in
the "afterCompletion() call" where the decision to commit should actually be
done in 2 phi commit... a bit of work there :) but feasable.
There are others problems that I can think of that we would need to discuss,
but as usual as long as we don't code.. no need to talk
marc
|
|-Dan
|
|
