Performance Considerations
Managing Contention
If two transactions , either standalone or across the cluster, attempt to perform a cache operation on the same element, the following rules apply:
The first transaction gets access
The following transactions block on the cache operation until either the first transaction completes or the transaction timeout occurs.
Note:
When an element is involved in a transaction, it is replaced with a new element with a marker that is locked, along with the transaction ID. The normal cluster semantics are used. Because transactions only work with consistency=strong caches, the first transaction is the thread that manages to atomically place a soft lock on the element. (This is done with the CAS based putIfAbsent and replace methods.)
What Granularity of Locking is Used?
BigMemory Maxuses soft locks stored in the Element itself and is on a key basis.
Performance Comparisons
Any transactional cache adds an overhead, which is significant for writes and nearly negligible for reads. Compared to transactionalMode="off", the time it takes to perform writes will be noticeably slower with either "xa" or "local" specified, and "xa_strict" will be the slowest.