That won't work.
The UserTransaction is not a full transaction.
It does not have an enlistResource() method.
thanks Adrian. yes, i pretty much figured out that UserTransaction wouldn't work.
is there any way this can be done "with jboss"? i guess what i need is a transaction monitor service. does jboss provide it? or would you recommend a product/technology? thanks a lot.
You could try to configure the jboss one.
You will need an MBeanServer
(jboss-jmx.jar) and at least
There are other open source transaction monitors,
The main issue is that you have to do your own
enlisting of the XAResources in the transaction
(you are not in a managed environment).
I don't think I understand your config yet. On the client, do you have both a db connection and a jms connection(session) that you want to enroll in the same transaction?
If so I'd recommend you run jboss on the client, deploy a datasource/pool for the db, and use the local jboss transaction manager.
If you are making a call to a remote ejb (that does the db work on the remote jboss server) and using a jms connection both from the same client and want these both to be in the same transaction controlled from the client you need a distributed transaction. You should be able to do this now in jboss 4 with no special setup, just looking up UserTransaction on the client, but I haven't tried it and the dtm in jboss 4 is not really tested yet.
even if my db work is done through a remote ejb (on the same jboss server as jms topic), i need a distributed transaction, like you said.
are you saying jboss4's UserTransaction is a distributed transaction? or it will just handle this specific type of distributed transaction, where all the work is done on jboss.
i am somewhat confused by the difference between distributed transaction and transaction monitor you mentioned in the previous email. if the db work and jms are both invoked directly on the client, the transaction monitor would not use a distributed transaction, right? it would only enlist 2 XA resources, inside one local transaction?
thanks a lot for your help.
For me anyway,
distributed tx == jta transaction where at least one of the participants is a transaction manager in a different process
2pc tx == jta tx with at least 2 participants
My previous reply might have been misleading and/or partly wrong. I haven't actually tried most of what I'm suggesting so there could be plenty of errors left:-)
In jboss 4, getting a UserTransaction will install an mbean server (if not present) and the jboss tm (if not present) with no transaction logging. The UserTransaction will use the local tm. Therefore you can do 2pc tx and distributed tx (as long as the communication is supported, which means right now only with other jboss instances). However, since there is no tx logging, you won't have recovery features.
To enroll jms in a jta transaction, jms needs to be accessed through the jmsra adapter. To get this on a client, you'd currently have to be running your client inside a jboss instance that has at least the transaction and jca stuff installed. In jboss 4, the transaction stuff is automatically installed on a client when you get a UserTransaction, but the jca stuff isn't, and there is no easy way I can think of to install it automatically, at least without the concept of an Application Container.
Lets suppose that you have found a way to deploy your client running in some configuration of jboss and you have deployed jmsra locally. In jboss 4, you can access remote ejbs and (local) jms(ra) within the same UserTransaction: this is a distributed transaction, since the remote ejb gets enrolled in the tm of the remote jboss instance. In jboss 3, you can't access remote ejbs within the same transaction. You could deploy a datasource on the client and access both the local datasource and the (local) jms(ra) within the same 2pc non-distributed transaction.
My understanding is that without running your client in a jboss instance and accessing jms through jmsra, jms activity will not be enrolled in a client UserTransaction.
One other possibility is to write a session bean whose function is to send the message and to do the db access through session beans also. If you start a client side UserTransaction and access these session beans they will all be enrolled in the tx. The communication overhead should be approximately the same for the jms part, since you have replaced sending the message between client and server vms through jms with sending it through the ejb call transport.
David, your detailed explanation is really appreciated.
so basically you are saying jboss4's user transaction is distributed transaction. and even so, jboss still is necessary to have jms enrolled in the UserTransaction. this all makes sense to me.
i cannot use the session bean approach you suggested, 'cause my jms work actually is a receive, not a publish. my client is supposed to wait for a message and then do some db work. i guess starting a jboss on the client is the only way to go.
in this case, do i have to use MDB on the client jboss (which means all the jboss servers have to be in a cluster to get the topic jndi?), or can i still write standalone jms code inside jboss wthout using MDB? in the latter case, does jms get enrolled into transaction context?
one last question, would you explain what "no logging/recovery feature for UserTransaction" means? i understand the ACID properties of transactions. but when the transaction is committed, the change is made to db, which takes care of recovery for it, right? would you give a concerete example?
thanks a lot.