On 17 Jun 2013, at 11:52, Pedro Ruivo <pe...@infinispan.org> wrote: > I've been looking at TxDistributionInterceptor and I have a couple of > questions (assuming REPEATABLE_READ isolation level): > > #1. why are we doing a remote get each time we write on a key? (huge > perform impact if the key was previously read) indeed this is suboptimal for transactions that write the same key repeatedly and repeatable read. Can you please create a JIRA for this? > > #2. why are we doing a dataContainer.get() if the remote get returns a > null value? Shouldn't the interactions with data container be performed > only in the (Versioned)EntryWrappingInterceptor? This was added in the scope of ISPN-2688 and covers the scenario in which a state transfer is in progress, the remote get returns null as the remote value was dropped (no longer owner) and this node has become the owner in between.
> > #3. (I didn't verify this) why are we acquire the lock is the remote get > is performed for a write? This looks correct for pessimistic locking but > not for optimistic... I think that, given that the local node is not owner, the lock acquisition is redundant even for pessimistic caches. Mind creating a test to check if dropping that lock acquisition doesn't break things? > > After this analysis, it is possible to break the isolation between > transaction if I do a get on the key that does not exist: > > tm.begin() > cache.get(k) //returns null > //in the meanwhile a transaction writes on k and commits > cache.get(k) //return the new value. IMO, this is not valid for > REPEATABLE_READ isolation level! Indeed sounds like a bug, well spotted. Can you please add a UT to confirm it and raise a JIRA? Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev