The correct way of using Jboss Transaction

[mckeno]

Hi all,

I read this in : http://docs.jboss.com/jbossas/guides/j2eeguide/r2/en/html_single/#d0e8494

The ClientUserTransactionService MBean publishes a UserTransaction implementation under the JNDI name UserTransaction. When the UserTransaction is obtained with a JNDI lookup from a external client, a very simple UserTransaction suitable for thin clients is returned. This UserTransaction implementation only controls the transactions on the server the UserTransaction object was obtained from. Local transactional work done in the client is not done within the transactions started by this UserTransaction object

So my question is does the sentence "UserTransaction implementation only controls the transactions on the server the UserTransaction object was obtained from" means that only the transaction between the Application Server and client is taken cared.
For my project, i want to have a User Transaction span across different modules (like module one process a message and record to DB, module Two process that message and make some other changes and record t DB), so it seems that I need an implementation of JTA which will provide me with a UserTransaction and various resource like JDBC, JMS transaction should be a branch or part of the global user transaction....and it seems that the UserTransaction MBean won't satisfy my need???

[kconner]

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.

[mckeno]

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
http://jotm.objectweb.org/doc/jotm.pdf
Atomikos
http://www.atomikos.com/products.html
Looks like somehow they describe the issue i mentioned, So it there anyway to accomplish that in Jboss?

[kconner]

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.

[marklittle]

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).

[kconner]

Not only that but the acknowledgments and delivery of JMS messages do not occur until the enclosing transaction commits :)

[weston.price]

Well, you would hope so. JBM does it in reverse.

[kconner]

JBM does what in reverse?

[weston.price]

Everything. It's a mess.

Ask Tim Fox....tell him I sent you.

[mckeno]

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...

[kconner]

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.