Transaction replication and distribution
Transactions and replication/distribution  Let's take a simple example to depict how transactions are being implemented in Infinispan and how they interact with the transaction manager.  TransactionManager tm = getTransactionManager(); tm.begin();//1 cache.put(k1,v1);//2 cache.remove(k2);//3 tm.commit();//4  On (1) the transaction manager creates a new Transaction object and associates it with the current thread. When (2) takes place, Infinispan acquires a local lock on k1, and associates it with the running transaction. Conceptually, a local lock is different from a cluster lock in the following:  if the lock is local, same lock (i.e. on same key) can be acquired on another node in the cluster at the same time. E.g. another transaction can successfully acquire a lock on k1, on another node.  on the same node where the k1 lock was acquired, any other transaction trying to acquire same lock will wait as the lock on k1 is already acquired  local locks are cheaper, as they don't required RPCs  Within the same call, Infinispan registers an XAResource against the running transaction. This XAResource is called by the TransactionManager on commit (rollback). For more details see step (4). Note that if useEagerLocking is set to true then cluster locks are being acquired at step (2) and (3). This decreases performance as RPC calls are being performed for every cache operation. On (3), we acquire a local lock is being acquired on k2 On (4)  the TransactionManager calls prepare on all registered XAResources. In this case the only registered resource is Infinispan's, at step 2.  once prepare call is received, Infinispan tries to acquire cluster locks for each acquired local lock. This involves RPC calls to other node is the cluster  if cluster locks can be acquired for all local locks, then it acknowledges to the TransactionManager that it is prepared(first phase of 2PC) and it is ready to commit the transaction. It is possible that cluster locks cannot be acquired at this step, e.g. if another transaction is in the process of committing and it has a lock on k1.  if the TransactionManager receives successful acknowledges from all registered XAResources, it calls commit on all resources (or calls rollback, if at least one of them failed to acknowledge the prepare). This is the second phase of the 2PC protocol. At this point Infinispan applies all the changes (it already has the locks) and releases the cluster locks. This also involves RPC calls to all nodes where the data resides. These RPC calls can be performed either synchronously or asynchronously, according to syncCommitPhase or syncRollbackPhase attribute The fact that Infinispan acquires cluster locks lazily(at commit time) has a significant performance impact, as the number of RPC calls is reduced.