I currently have Infinispan configured to enlist as a XAResource (FULL_XA) and use pessimistic locking.
<cache-container name="modeshape" default-cache="repo" module="org.modeshape"> <transport lock-timeout="60000"/> <replicated-cache name="repo" mode="SYNC"> <locking isolation="READ_COMMITTED" striping="false"/> <transaction mode="FULL_XA" locking="PESSIMISTIC"/> <string-keyed-jdbc-store shared="true" preload="false" passivation="false" purge="false" datasource="java:jboss/datasources/MyDS"> <string-keyed-table prefix="modeshape"> <id-column name="id" type="VARCHAR(200)"/> <data-column name="datum" type="LONGBLOB"/> <timestamp-column name="version" type="BIGINT"/> </string-keyed-table> </string-keyed-jdbc-store> </replicated-cache> </cache-container>
The application uses FULL_XA as the I also have JMS and JDBC XA Resources enlisted in the same transaction as Infinispan.
The application uses PESSIMISTIC locking (writeSkew=disabled) because the application often sees concurrent modification of cache entries is and is the recommended setting when configuring and infinispan cache for use in modeshape which is my current use case.
Applications that may be concurrently updating the same nodes should use Infinispan configured to use pessimistic locking with the READ_COMMITTED isolation level. By default Infinispan will use optimistic locking; this is more efficient for applications that don't update the same nodes, but concurrently updating the same nodes with optimistic locking may very well cause some updates to be lost. If you're not sure, use pessimistic locking.
After reading the Infinispan documentation and performing some tests it appears that if I uses PESSIMISTIC locking (writeSkew=disabled) then the Infinispan transaction is performed as an independent one-phase-commit separate from the other XAResources in the transaction.
If the write skew check is not enabled, then all the transaction are committed in one phase (independently if Infinispan is enlisted as Synchronization or XaResource).
Does this mean that the other resources enlisted in the transaction may not be rollback if they have already been committed and and error occurs during in the execution of the infinispan transaction?
If this is the case what if any options do I have to ensure all resources are co-ordinated in the same transaction while guarding against high contention on keys?
Many thanks in advance.