Can you explain your requirements further?
The service you are describing is just a proxy to the transaction state on the application server. This service allows a client to demarcate transactions on that server, controlling when they are started and how they are terminated.
If your client created a transaction and then were to make multiple calls to that server then all resources used by those calls would be enlisted into the same transaction.
Do you require distributed transactions? If so then you need to be looking at JBossTS, specifically the JTS version.
Thanks for your information.
Well for my requirement, it is like this:
I have like 3 or 4 java applications modules. Each of these modules is to be run on different server. A module reads in a message from a JMS queue process it and put in to the second JMS queue, the other modules will fetch the processed message from that queue and so on the the next module and next queue. During the processing of each application module, they will also do some saving to database too.
So in order to control the distributed modules and their related resource, like JDBC resource JMS...I think of applying JTA. So looks like i need an implementation of JTA which will provide me like a UserTransaction and I will have the related resource "register" or bind to this global UserTransaction
I have look at some products like JOTM
Looks like somehow they describe the issue i mentioned, So it there anyway to accomplish that in Jboss?
If you are using JMS between the modules then you will not require distributed transactions.
Each module should have a local JTA transaction covering the reading of the message, subsequent processing and writing of the message for the next module.
There is nothing in JOTM or Atomikos that cannot be accomplished in JBossTS. You can wrap you JMS receipt and db update into a single transaction. However, there is no standard to allow you to glue together multiple JMS queue manipulations (enqueue/dequeue+db/enqueue/dequeue+db/enqueue/dequeue+db) into a single transaction because the transaction information does not flow with the message(s).
Not only that but the acknowledgments and delivery of JMS messages do not occur until the enclosing transaction commits :)
Well, you would hope so. JBM does it in reverse.
JBM does what in reverse?
Everything. It's a mess.
Ask Tim Fox....tell him I sent you.
Thanks for all the input,
What is JBM anyway, is it JBossMessaging?
I am not really sure about this UserTransaction, when I read about JTA they say that
The Java Transaction API consists of three elements: a high-level application transaction demarcation interface, a high-level transaction manager interface intended for an application server, and a standard Java mapping of the X/Open XA protocol intended for a transactional resource manager.
Basically, I am still not clear of difference between UserTransaction, and TransactionManager.
For my requirement, each java app module will fetch data from JbossMQ JMS Queue and then process it make some changes to DB pass on the message to another JMS Queue, another java app fetches that message and do the same....
So could I have some kind of a global transaction that look after the whole process sequence, say like at the last java app if something went wrong and I decide to roll back some or all of the operation happened and committed locally before in the previous java app module.
That's why I want to make use of the 2 phase commit of JTA framework. Atomikos describes that we can accomplished that by propagating the UserTransaction through the JMS Queue. It is like at first somehow we create a UserTransaction object in an java app after it is finished we send the message to next queue along with the UserTransaction object...
I tried to look at the Jboss UserTransaction MBean but it doesn't to fit? so maybe JbossTS should have sth suitable...
Well, you can certainly use JMS to propagate the transaction context but this would mean that the JMS messages were non transactional.
If they were transactional then the JMS messages would not be sent until the transaction committed.
You would need to use the JTS version of JBossTS in order to handle distributed transactional processing if the apps are in different VMs.
If you are running within AS then you can obtain the propagation context using the TransactionPropagationContextExporter/TransactionPropagationContextImporter bound in JNDI. These will provide you with an object that can be sent across the wire and used on the other end to recreate the transaction.