[infinispan-dev] Invocation and transaction contexts
Picking up from a few q's Mircea asked on IRC earlier while I was away:
mmarkus:manik, I understand your point with that
mmarkus:What I wanted to say is to have to implementations of
InvocationContext interface, TxInvocationContext and
NonTxInvocationContext
mmarkus:the code from GetKeyValueCommand would look the same, only
difference is that at runtime it works with different
implementations, depending on weather it runs in a tx context or not
So a quick recap for those who missed the conversation on IRC:
InvocationContext (IC) and TransactionContext (TC) are interfaces that
both extend EntryLookup and FlagContainer.
This is so that entries wrapped for MVCC guarantees (as
RepeatableReadEntries or ReadCommittedEntries) are stored in the
context. Also, optional Flags, such as forcing local mode, are also
stored in the context. The reason why we have 2 different types of
contexts is that if the call is transactional, some of this needs to
be available for the duration of the entire transaction.
To enable transparent switching between the appropriate context in
use, implementations of methods on EntryLookup in the IC checks a TC
first, e.g.,
@Override
public CacheEntry lookupEntry(Object k) {
if (transactionContext != null) {
return transactionContext.lookupEntry(k);
} else {
return lookedUpEntries == null ? null :
lookedUpEntries.get(k);
}
}
Mircea, so from what I gather, you're proposing 2 separate IC impls,
one that does this check-and-delegate and one that does not, and the
appropriate one is set up by the InvocationContextInterceptor (ICI).
While this does make sense, unfortunately ICs are built much earlier,
in the CacheDelegate, Notifier (when isolating contexts for
callbacks), or the CommandAwareRpcDispatcher (for inbound calls over
the network). This is before we are aware of the presence of absence
of any transactions which may be in scope.
The other possibility is for the ICI to copy a non-tx-aware IC to a tx-
aware one. But IMO the construction and copy will outweigh the cost
of the if block and the relative code ugliness.
Maybe there is another way, perhaps I have missed something?
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org