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.

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.