About Transaction Support
BigMemory Max supports Global Transactions, with "xa_strict" and "xa" modes, and Local Transactions with "local" mode.
For more discussion on these modes, and related topics, see "Working With Transactional Caches" in the Configuration Guide for BigMemory Max.
All or Nothing
If a cache is enabled for transactions, all operations on it must happen within a transaction context otherwise a TransactionException will be thrown.
Transactional Methods
The following methods require a transactional context to run:
put()
get()
getQuiet()
remove()
getKeys()
getSize()
containsKey()
removeAll()
putWithWriter()
removeWithWriter()
putIfAbsent()
removeElement()
replace()
This list is applies to all transaction modes.
All other methods work non-transactionally but can be called on a transactional cache, either within or outside of a transactional context.
Change Visibility
The isolation level offered by BigMemory’s Ehcache is READ_COMMITTED. Ehcache can work as an XAResource, in which case, full two-phase commit is supported. Specifically:
All mutating changes to the cache are transactional including put(), remove(), putWithWriter(), removeWithWriter(), and removeAll().
Mutating changes are not visible to other transactions in the local JVM or across the cluster until COMMIT has been called.
Until then, reads such as by cache.get(...) by other transactions return the old copy. Reads do not block.
Transactional Modes
Transactional modes enable you to perform atomic operations on your caches and other data stores.
local — When you want your changes across multiple caches to be performed atomically. Use this mode when you need to update your caches atomically. That is, you can have all your changes be committed or rolled back using a straightforward API. This mode is most useful when a cache contains data calculated from other cached data.
xa — Use this mode when you cache data from other data stores, such as a DBMS or JMS, and want to do it in an atomic way under the control of the JTA API ("Java Transaction API") but without the overhead of full two-phase commit. In this mode, your cached data can get out of sync with the other resources participating in the transactions in case of a crash. Therefore, only use this mode if you can afford to live with stale data for a brief period of time.
xa_strict — Similar to "xa" but use it only if you need strict XA disaster recovery guarantees. In this mode, the cached data can never get out of sync with the other resources participating in the transactions, even in case of a crash. However, to get that extra safety the performance decreases significantly.