My advice would be to:
1. Check out JBoss Cache from SVN and get it to build.
2. Take a look at TxInterceptor.java line 1243 or so. Try to get it to work.
3. You can configure the unit test suite to use your TX manager, see if you can't get it to work with Atomikos.
4. Unfortunately I don't see a way to configure the TxInterceptor. Create a JIRA issue and explain you want to configure this behavior.
Actually, it seems like you can mark a method as @Inject and JBoss Cache will inject a configuration object. Not sure if there's any XML that pertains to the TX interceptor.
Sounds like a potential bug. Once the transaction has completed, asking the Transaction object its status should return STATUS_NO_TRANSACTION (it's finished and been cleaned up) or perhaps STATUS_COMMITTED
Guy Pardon of Atomikos justifies his use of "UNKNOWN" saying:
I think the status cannot be determined for the following reason. Imagine transaction A started in a remote VM and imported in the local VM subsequently. Also, suppose the local VM only does READ_ONLY work.
Then, image two-phase commit:
-transaction A prepares
-the local VM returns READ_ONLY for all its work
-transaction A commits
-transaction A prepares
-the local VM returns READ_ONLY
-transaction A rolls back
Both cases are indistinguishable by the semantics of the READ_ONLY on prepare: no further outcome is desired.
IMHO, therefore the only state that makes sense is UNKNOWN. It would be a mistake to say COMMITTED, and likewise for ROLLEDBACK.
Guy has later said that perhaps he could use "NO TRANSACTION" in such a situation as well, however, it appears the JBossCache 1.4.x code will behave the same for NO_TRANSACTION as it does for "UNKNOWN".
Thoughts? Here is the thread on the Atomikos forum.
Thanks for your thoughts on this. Basically, there is a fundamental flaw in the way JBC deals with Sync callbacks, in that we only commit stuff in the cache in the afterCompletion() callback. There are good reasons why we do this, but in the end it is incorrect and we are working on a better mechanism, one of which is to implement XA interfaces.
See http://jira.jboss.org/jira/browse/JBCACHE-70. Sadly, it is not currently high on the prio list since the workaround currently in place works for most JTA compliant TMs out there.
Feel free to vote on the JIRA though to bump up it's prio.