What about the tx logging/recovery being developed in head? If you want to participate in that you would want to use the server tm. The legacy approach can be used by developing an alternate TxManager that is based on the JTA version and allowing the TxManager to be plugged in.
The name TxManager in JBossMQ is misleading.
It should be TxRepository or something like it.
I don't understand why you are using a JTA transaction manager?
Is this intended to support things like bridging where you need 2PC?
Are you trying to become a sub-coordinater?
JMS is a "local" branch of a JTA transaction.
i.e. it exposes an XAResource which is driven by an external JTA transaction.
JTA Transaction -> JMSXAResource -> local branch prepare/commit logging
You should be writing what the spec calls a ResourceManager not a TransactionManager.
A resource manager does keep track of transactions
(to hold the association: xid->data)
it doesn't control the transaction or keep track of thread association, etc.
It is a "slave", unless it is doing heuristics. :-)
I am using the JT API. The TransactionManager doesn't necessarily have to be the JBoss TransactionManager. It is just a mechanism to associate something with the current thread and a way to start, commit or rollback a transaction.
We don't really *need* a JTA transaction manager on the server side, as Adrian has pointed out.
However it does provide some usefuly hooks via the Synchronization interface so we can do the stuff that we need to do at prepare and commit time, rather than rolling our own.
(The XA resource transaction logging is currently not implemented for prepare and commit so I've added a JIRA task for that.)
We're not currently enrolling any XAResources into this transaction manager instance, so it's role for us is really just as a way of managing what we have to do at prepare and commit time in order to satisfy the XA protocol from the resources point of view.
Currently we are actually using the same *instance* of the transaction manager as used by jboss as. (we're looking it up from the well known JNDI name)
I think perhaps it would be better for the jms server to have it's own private instance so we can avoid suspend and resume calls as mentioned previously.
But a JTA transation manager is overkill for what you are doing.
The logging is very different for a start.
All you need is an xid -> resource/synchronization map like JBossMQ.
Where resource is local tx state (logically added and acknowledged messages).
This is the one piece of JBossMQ that is actually done well,
although it is missing any sort of management exposure.
I don't like the idea of passing tx context in a thread local.
They serve different purposes.
JTA Transaction = Logical unit of work that holds links to the real resources + other things
It is a thread local such that it can pass under application interfaces.
Local Transaction = Real state
This should be passed explicitly in the ResourceManager protocol's. Its never "in context"
during the application. In fact, the TM can invoke on the ResourceManager in
fairly complicated ways.
tm.begin(); Transaction tx1 = tm.getTransaction(); tx1.enlistResource(jms1); tx1.delistResource(jms1); tx1.enlistResource(jms2); // Two jms xaresources for the same transaction tx1.delistResource(jms2); tm.suspend(); // No thread local transaction tm.begin(); Transation tx2 = tm.getTransaction(); tx2.enlistResource(jms1); // Resource is now associated with a different tx tx1.commit(); // But can still commit with the old XID