[infinispan-dev] Invocation and transaction contexts

Mircea Markus mircea.markus at jboss.com
Fri Apr 17 04:27:29 EDT 2009


Thanks for the clarifications mate, all makes perfect sense to me now.
Manik Surtani wrote:
> 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
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev




More information about the infinispan-dev mailing list