[infinispan-dev] Invocation and transaction contexts

[Manik Surtani]

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 at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org