Chapter 27. Transactions

27.1. About Java Transaction API

Red Hat JBoss Data Grid supports configuring, use of, and participation in Java Transaction API (JTA) compliant transactions.

JBoss Data Grid does the following for each cache operation:

  1. First, it retrieves the transactions currently associated with the thread.
  2. If not already done, it registers an XAResource with the transaction manager to receive notifications when a transaction is committed or rolled back.

27.2. Configure Transactions (Library Mode)

In Red Hat JBoss Data Grid, transactions in Library mode can be configured with synchronization and transaction recovery. Transactions in their entirety (which includes synchronization and transaction recovery) are not available in Remote Client-Server mode.

In order to execute a cache operation, the cache requires a reference to the environment’s Transaction Manager. Configure the cache with the class name that belongs to an implementation of the TransactionManagerLookup interface. When initialized, the cache creates an instance of the specified class and invokes its getTransactionManager() method to locate and return a reference to the Transaction Manager.

In Library mode, transactions are configured as follows:

Configure Transactions in Library Mode (Programmatic Configuration)

  1. Enable Transactions

    Configuration config = new ConfigurationBuilder()/* ... */.transaction()
            .transactionMode(TransactionMode.TRANSACTIONAL)
            .transactionManagerLookup(new GenericTransactionManagerLookup())
            .lockingMode(LockingMode.OPTIMISTIC)
            .useSynchronization(true)
            .recovery()
                .recoveryInfoCacheName("anotherRecoveryCacheName").build();
    1. Set the transaction mode.
    2. Select and set a lookup class. See the table below this procedure for a list of available lookup classes.
    3. The lockingMode value determines whether optimistic or pessimistic locking is used. If the cache is non-transactional, the locking mode is ignored. The default value is OPTIMISTIC.
    4. The useSynchronization value configures the cache to register a synchronization with the transaction manager, or register itself as an XA resource. The default value is true (use synchronization).
    5. The recovery parameter enables recovery for the cache when set to true.

      The recoveryInfoCacheName sets the name of the cache where recovery information is held. The default name of the cache is specified by RecoveryConfiguration.DEFAULT_RECOVERY_INFO_CACHE.

  2. Configure Write Skew Check

    The writeSkew check determines if a modification to the entry from a different transaction should roll back the transaction. Write skew set to true requires isolation_level set to REPEATABLE_READ. The default value for writeSkew and isolation_level are false and READ_COMMITTED respectively.

    Configuration config = new ConfigurationBuilder()/* ... */.locking()
            .isolationLevel(IsolationLevel.REPEATABLE_READ).writeSkewCheck(true);
  3. Configure Entry Versioning

    For clustered caches, enable write skew check by enabling entry versioning and setting its value to SIMPLE.

    Configuration config = new ConfigurationBuilder()/* ... */.versioning()
            .enable()
            .scheme(VersioningScheme.SIMPLE);

Table 27.1. Transaction Manager Lookup Classes

Class NameDetails

org.infinispan.transaction.lookup.DummyTransactionManagerLookup

Used primarily for testing environments. This testing transaction manager is not for use in a production environment and is severely limited in terms of functionality, specifically for concurrent transactions and recovery.

org.infinispan.transaction.lookup.JBossStandaloneJTAManagerLookup

The default transaction manager when Red Hat JBoss Data Grid runs in a standalone environment. It is a fully functional JBoss Transactions based transaction manager that overcomes the functionality limits of the DummyTransactionManager.

org.infinispan.transaction.lookup.GenericTransactionManagerLookup

GenericTransactionManagerLookup is used by default when no transaction lookup class is specified. This lookup class is recommended when using JBoss Data Grid with Java EE-compatible environment that provides a TransactionManager interface, and is capable of locating the Transaction Manager in most Java EE application servers. If no transaction manager is located, it defaults to DummyTransactionManager.

org.infinispan.transaction.lookup.JBossTransactionManagerLookup

The JbossTransactionManagerLookup finds the standard transaction manager running in the application server. This lookup class uses JNDI to look up the TransactionManager instance, and is recommended when custom caches are being used in JTA transactions.

Note

It is important to note that when using Red Hat JBoss Data Grid with Tomcat or an ordinary Java Virtual Machine (JVM), the recommended Transaction Manager Lookup class is JBossStandaloneJTAManagerLookup, which uses JBoss Transactions.

27.3. Transactions Spanning Multiple Cache Instances

Each cache operates as a separate, standalone Java Transaction API (JTA) resource. However, components can be internally shared by Red Hat JBoss Data Grid for optimization, but this sharing does not affect how caches interact with a Java Transaction API (JTA) Manager.

27.4. The Transaction Manager

Use the following to obtain the TransactionManager from the cache:

TransactionManager tm = cache.getAdvancedCache().getTransactionManager();

To execute a sequence of operations within transaction, wrap these with calls to methods begin() and commit() or rollback() on the TransactionManager:

Performing Operations

tm.begin();
Object value = cache.get("A");
cache.remove("A");
Object prev = cache.put("B", value);
if (prev == null)
    tm.commit();
else
    tm.rollback();

Note

If a cache method returns a CacheException (or a subclass of the CacheException) within the scope of a JTA transaction, the transaction is automatically marked to be rolled back.

To obtain a reference to a Red Hat JBoss Data Grid XAResource, use the following API:

XAResource xar = cache.getAdvancedCache().getXAResource();