| Author |
Message
|
| wmq_guy |
 Posted: Wed Nov 17, 2004 2:50 pm Post subject: must use XA enable setting? |
 |
|
Acolyte
Joined: 21 Oct 2004
Posts: 50
|
I have an MDB that grabs messages off a queue, creates a dto and and within the onMessage calls a session bean to use the dto to make a new message and put it on a remote queue. I have it working fine, but if I turn off XA enable on the two QCF's it barks, does this mean I have to use it??
I really do not want to use XA
here is the systemout log
| Quote: |
11/17/04 11:14:46:719 EST] 5cb6e401 TransactionIm E WTRN0062E: An illegal attempt to use multiple resources that have only one-phase capability has occurred within a global transaction.
[11/17/04 11:14:46:844 EST] 5cb6e401 LocalTransact E J2CA0030E: Method enlist caught java.lang.IllegalStateException
at com.ibm.ejs.jts.jta.TransactionImpl.enlistResource(TransactionImpl.java:546)
at com.ibm.ejs.jts.jta.JTSXA.enlistResource(JTSXA.java:1061)
at com.ibm.ejs.jts.jta.JTSXA.enlistOnePhase(JTSXA.java:1038)
at com.ibm.ejs.j2c.LocalTransactionWrapper.enlist(LocalTransactionWrapper.java:493)
at com.ibm.ejs.j2c.ConnectionEventListener.localTransactionStarted(ConnectionEventListener.java:531)
at com.ibm.ejs.jms.JMSManagedSession.localTransactionStarted(JMSManagedSession.java:853)
at com.ibm.ejs.jms.JMSManagedSession.enlist(JMSManagedSession.java:809)
at com.ibm.ejs.jms.JMSMessageProducerHandle.enlist(JMSMessageProducerHandle.java:795) |
|
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Nov 17, 2004 2:58 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you are not posting to the target queue from within the same session as the receiving queue you need a 2 phase commit.
Anyway your transaction is setup for 2 phase commit. Stick with XA!
F.J. |
|
| Back to top |
|
|
| wmq_guy |
| Posted: Mon Nov 22, 2004 3:48 pm Post subject: |
|
|
Acolyte
Joined: 21 Oct 2004
Posts: 50
|
So if I want to elimate this XA enable tran, what exactly could I do?
the MDB is not allowed to call the other session bean directly or they are tied together making it a global tran forcing me to use XA..
should I have the MDB push all the work over to another bean and have it call the SLSB, isnt that the same thing?
I want the MDB to lookup the SLSB and pass the handle around the system with data and forget about it, not wait until the SLSB's method is call later down the road and then terminate..
any ideas? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Nov 22, 2004 8:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You have the typical setup for a 2 phase commit. You are dealing with 2 different qcf
| wmq_guy wrote: |
I have an MDB that grabs messages off a queue, creates a dto and and within the onMessage calls a session bean to use the dto to make a new message and put it on a remote queue. I have it working fine, but if I turn off XA enable on the two QCF's it barks, does this mean I have to use it??
I really do not want to use XA |
I really do not understand why you are so reluctant to use XA. This is the typical scenario for it. How can you have a secure transaction if you do not do a 2 phase commit accross the queues and qcfs ? Especially using an MDB.
Stick with 2 phase commit and you'll be fine.
F.J.  |
|
| Back to top |
|
|
| slaupster |
| Posted: Mon Dec 06, 2004 5:35 am Post subject: |
|
|
Apprentice
Joined: 17 Nov 2004
Posts: 41
|
it sounds like you have the tran settings on the dtd for either your MDB or your EJB set to required when you don't in fact want the work done in a tran.
If you have the dtd tran setting on the MDB or the EJB method set to require a tran, then the JCA resources used during work done by the MDB and the EJB method must be XA enabled, and the tran will flow over any work done with these resources, with the tran boundaries set by the container.
If you don't want the overhead of all this tran work, and don't care about success or failure, you can deselect XA enabled on the resources provided you don't use the reource in a tran context. In order to do this, you're dtd settings for the MDB and EJB must be set to 'Bean' (ie the app developer will handle it, so effectively none) and 'Never' respectively.
'Never' on the EJB method will ensure that even if the MDB wants the EJB method to work in a tran context, it won't so you'll get an exception. |
|
| Back to top |
|
|
| wmq_guy |
| Posted: Mon Dec 06, 2004 7:38 am Post subject: |
|
|
Acolyte
Joined: 21 Oct 2004
Posts: 50
|
perfect answer. Wish I had talked to you earlier and saved a ton of time.
I had changed the AssDesc. to not supported for the MDB and EJB , unchecked XA and voila!
Now I can concetrate on exactly how I would like to run.
I am considering making two MDB's one that 'REQUIRED' and one that does not and then setting the EJB to "SUPPORTS"
so, depending on which MDB calls the EJB it would be a XA global tran or not.
sound like I'm going the right way?
only thing is I would then have to make 3 different QCF's..is that a bad thing or should affect much? |
|
| Back to top |
|
|
| slaupster |
| Posted: Mon Dec 06, 2004 8:16 am Post subject: |
|
|
Apprentice
Joined: 17 Nov 2004
Posts: 41
|
that sounds like a perfect use of "supports".
There is no harm in using 3 at all - its still going to require the same number of JMS resources to do the work, and it will be a bit neater and easier to manage.
Your only consideration is the work load you are going to push through your EJB and the requirements that will place on the QCF that it uses. The default listener port settings, I believe, are max 1 session and max 1 message, therefore you're EJB will only be handling 1 thread of work in the transactional context, and 1 thread in the non-transactional context, so max of 2 threads - this is well below the default max 10 Connections in the Connection Pooling settings on the QCF. If you start to push MDB capacity up by increasing the number of Sessions at the listenerport, then you may need to configure the connection pool settings for your EJB's QCF to accomodate this - a max of hundreds of connections is not unusal!
Remember that your messages are not processed serially in this configuration. Good luck! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 06, 2004 9:10 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Remember without a 2 phase commit there is the potential for loss of data synchronization.
Most of the time it will work, but without 2 phase commit you can no longer guarantee the "guaranteed delivery once only" paradigm.
Enjoy |
|
| Back to top |
|
|
|
|
