Re: [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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev