Mostly. The "xa_strict" mode is not supported due to each version of WebSphere being a custom implementation. That is, it has no stable interface to implement against. However, "xa", which uses TransactionManager callbacks, and "local" modes are supported.

When using Spring, make sure your configuration is set up correctly with respect to the PlatformTransactionManager and the WebSphere TM.

To confirm that Ehcache will succeed, try to manually register a com.ibm.websphere.jtaextensions.SynchronizationCallback in the com.ibm.websphere.jtaextensions.ExtendedJTATransaction. Get java:comp/websphere/ExtendedJTATransaction from JNDI, cast that to com.ibm.websphere.jtaextensions.ExtendedJTATransaction and call the registerSynchronizationCallbackForCurrentTran method. If you succeed, Ehcache should too.

Ehcache is a "transactional" cache for Hibernate purposes. The net.sf.ehcache.hibernate.EhCacheRegionFactory supports Hibernate entities configured with <cache usage="transactional"/>.

WebLogic uses an optimization that is not supported by the Ehcache implementation. By default WebLogic 10 spawns threads to start the transaction on each XAResource in parallel. Because we need transaction work to be performed on the same Thread, you must turn off this optimization by setting the parallel-xa-enabled option to false in your domain configuration:

Atomikos has a bug, which makes the "xa" mode's normal transaction termination mechanism unreliable. There is an alternative termination mechanism built in that transaction mode that is automatically enabled when net.sf.ehcache.transaction.xa.alternativeTerminationMode is set to true or when Atomikos is detected as the controlling transaction manager.

This alternative termination mode has strict requirement on the way threads are used by the transaction manager and Atomikos’s default settings will not work unless you configure the following property as shown below: