-
30. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
ovidiu.feodorov Aug 31, 2006 5:22 PM (in response to clebert.suconic)timfox wrote:
If we're really that bothered the place to get an answer (maybe) from the spec authors is the jms-interest mailing list at Sun.
Good idea. I'll do that. -
31. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
timfox Aug 31, 2006 5:32 PM (in response to clebert.suconic)Actually this gets more complex.
There are some situations where sending messages directly if the transaction is not enlisted in a global tx will give incorrect behaviour.
See this comment from MesagingXAResource://If I commit/rollback the tx, then there is a short period of time between the AS (or whoever) //calling commit on the tx and calling start to enrolling the session in a new tx. //If the session has any listeners then in that period, messages can be received asychronously //but we want them to be received in the context of a tx, so we convert.
So we have to be very careful here.
AFAICT the only time when it would be valid to directly send messages using an XASession is if the session had never been enlisted in a global tx. -
32. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
ovidiu.feodorov Aug 31, 2006 5:44 PM (in response to clebert.suconic)Right, but we control the XASession/XAResource implementation, so we can case for it. If a session has been enlisted once, then it will be reenlisted again with the next transaction, unless it closes. This is the common behavior.
This is not the case we're talking, which is when the session did not see a transaction ever. -
33. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
timfox Aug 31, 2006 6:03 PM (in response to clebert.suconic)Another solution is for the JCA layer to be clever enough to realise there is no transaction and execute the jms operations using a standard Session rather than an XASession, then we avoid these problems.
-
34. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
ovidiu.feodorov Aug 31, 2006 6:10 PM (in response to clebert.suconic)If it did, we'd fall back to the exact behavior we actually want for Messaging, and it already happens in JBossMQ.
Remember that the JCA layer has nothing to do with the decision to send the message through, which is taken by SpyXAResourceManager in JBossMQ's case, and could be taken by MessagingResourceManager in ours.
The JCA layer just (correctly) does not enlist the XAResource with an inexistent JTA transaction. -
35. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
ovidiu.feodorov Sep 1, 2006 5:27 PM (in response to clebert.suconic)Alright, after 30+ messages, the conclusion is: we'll do it.