In support of the JTA specification, only prepared transaction data is recoverable. Prepared data is persisted onto the cluster and locks on the memory are held. This means that non-clustered caches cannot persist transaction data. Therefore, recovery errors after a crash might be reported by the transaction manager.

At any time after something went wrong, an XAResource might be asked to recover. Data that has been prepared might either be committed or rolled back during recovery. XA data that has not yet been prepared is discarded. The recovery guarantee differs depending on the XA mode.

With “xa” mode, the cache doesn't get registered as an {XAResource} with the Transaction Manager but merely can follow the flow of a JTA transaction by registering a JTA {Synchronization}. The cache can end up inconsistent with the other resources if there is a JVM crash in the mutating node. In this mode, some inconsistency might occur between a cache and other XA resources (such as databases) after a crash. However, the cache data remains consistent because the transaction is still fully atomic on the cache itself.

With “xa_strict” mode, the cache always responds to the Transaction Manager's recover calls with the list of prepared XIDs of failed transactions. Those transaction branches can then be committed or rolled back by the Transaction Manager. This mode supports the basic XA mechanism of the JTA standard.