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(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