[infinispan-dev] Issue about propagation of the RollbackCommand in Infinispan 5.2.0

[Mircea Markus]

On 17 Aug 2012, at 13:16, Sebastiano Peluso wrote:

> Hi all,
> 
> I have a question about the propagation of the RollbackCommand in 
> Infinispan 5.2.0 when I use the Optimistic locking scheme and the 
> Distribution clustering mode.
> 
> In particular I have noticed that a RollbackCommand command for a 
> transaction T is propagated on a set of nodes S even if T's coordinator 
> has never sent and it will never send a PrepareCommand command to nodes 
> in S.
> 
> I try to make clear the issue by the following example.
>  Suppose you have a transaction T executing on node N0 and T writes on 
> keys k0, k1, k2,...., km (m+1 keys) until it reaches the prepare phase. 
> In addition node Ni, with i=0,...,m+1, is the ki's primary owner. If at 
> prepare time, during the lock acquisition on the local node N0 (see 
> visitPrepareCommand method in OptimisticLockingInterceptor class) T 
> fails to acquire the lock on k0, an exception is thrown (e.g. 
> TimeoutException) and T will be rolled back. In this case, when T starts 
> the rollback phase, it seems to me that a RollbackCommand command is 
> multicast to all nodes Nj, with j=1,...,d, if k0 is sorted after kj 
> during the local lock acquisition (see acquireAllLocks method in 
> OptimisticLockingInterceptor), because:
> 
>  - shouldInvokeRemoteCommand method on the TxInvocationContext returns 
> true (see BaseRpcInterceptor class);
>  - getAffectedKeys on the TxInvocationContext returns the set {k1,..., 
> kd} (see visitRollbackCommand in DistributionInterceptor class).
> 
> Is it correct?
> 
> If I'm not wrong, which is the design choice behind this implementation?
This is indeed sub-optimal, but not incorrect.
Does this break the TOA/TOB stuff? Mind creating a JIRA for it?