About Transactional Caches
Transactional caches add a level of safety to cached data and ensure that the cached data and external data stores are in sync. Distributed caches can support Java Transaction API (JTA) transactions as an XA resource. This is useful in JTA applications requiring caching, or where cached data is critical and must be persisted and remain consistent with System of Record data.
However, transactional caches are slower than non-transactional caches due to the overhead from having to write transactionally. Transactional caches also have the following restrictions:
Data can be accessed only transactionally, even for read-only purposes. You must encapsulate data access with begin() and commit() statements. This may not be necessary under certain circumstances (see, for example, the discussion on Spring in "Transaction Support" in the
Developer Guide for BigMemory Max.
copyOnRead and
copyOnWrite must be enabled. These
<cache> attributes are "false" by default and must set to "true".
Caches must be strongly consistent. A transactional cache's
consistency attribute must be set to "strong".
Nonstop caches cannot be made transactional except in strict mode (xa_strict). Transactional caches in other modes must
not contain the
<nonstop> sub-element.
Objects stored in a transactional cache must override
equals() and
hashCode(). If overriding
equals() and
hashCode() is not possible, see
Implementing an Element Comparator.
Caches can be dynamically changed to bulk-load mode, but any attempt to perform a transaction when this is the case will throw a
CacheException.
For more information about transactional caches, see "Transaction Support" in the Developer Guide for BigMemory Max.
You can choose one of three different modes for transactional caches:
Strict XA – Has full support for XA transactions. May not be compatible with transaction managers that do not fully support JTA.
XAXA – Has support for the most common JTA components, so likely to be compatible with most transaction managers. But unlike strict XA, may fall out of sync with a database after a failure (has no recovery). Integrity of cache data, however, is preserved.
Local – Local transactions written to a local store and likely to be faster than the other transaction modes. This mode does not require a transaction manager and does not synchronize with remote data sources. Integrity of cache data is preserved in case of failure.
Note:
Both the XA and local mode write to the underlying store synchronously and using pessimistic locking. Under certain circumstances, this can result in a deadlock, which generates a DeadLockException after a transaction times out and a commit fails. Your application should catch DeadLockException (or TransactionException) and call rollback(). Deadlocks can have a severe impact on performance. A high number of deadlocks indicates a need to refactor application code to prevent races between concurrent threads attempting to update the same data.