-
15. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
Pissing off a lot of users and breaking their applications is always, of course, a source of major concern.
However, before that we should carefully consider what's the correct way of implementing something. If the old behavior is wrong, then I am afraid that we should take the risk. Fortunately, this seems not to be the case. It appears to me that we just simply need to fix JBM and let the users and their applications be.
The fact that java:/JmsXA is used in inappropriate circumstances has no bearing on the case at hand. The system should work correctly even if (slightly) abused. -
16. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
This is really a religious argument.
Personally I think JBoss MQ behaviour is wrong, but I also concede that we should change the behaviour to be the same as MQ but only so as not to break users stuff. -
17. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
timfox wrote:
Personally I think JBoss MQ behaviour is wrong
Why. Could you please elaborate on this? -
18. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
Because an XASession is supposed to be transactional and it's transactonal state transitions are supposed to be determined by the transaction manager invoking methods on it's XAResource.
JBoss MQ is adding an extra semantic by saying, as well as the above, if the XASession is not enlisted in any transaction it should act non transactionally.
This is not a semantic of the XASession as specified in the JMS spec.
As an analogy, if you obtained an XA database connection from Oracle but forgot to enlist it in a transaction, then did some database operations, you would be suprised if you discovered it had gone into auto commit mode.
But that is exactly what you are expecting a jms xa connection to do.
To me that seems counter intuitive (and possibly dangerous). -
19. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
timfox wrote:
Because an XASession is supposed to be transactional and it's transactonal state transitions are supposed to be determined by the transaction manager invoking methods on it's XAResource.
XASession is supposed to be transactional only if its XAResource is enrolled in a transaction. This is not the case for the situation we discuss. There's no active JTA transaction at the time of session creation. The transaction manager cannot modify the state of the session, since there's no association with any transaction. Hence, the specific session we talk about is non-transactional (even if the object instance associated with the session implements XASession. It's the same as saying that an object that implements Runnable must have its run() method executed by a thread at all times).timfox wrote:
JBoss MQ is adding an extra semantic by saying, as well as the above, if the XASession is not enlisted in any transaction it should act non transactionally.
In my opinion JBossMQ is just adding common sense.timfox wrote:
As an analogy, if you obtained an XA database connection from Oracle but forgot to enlist it in a transaction, then did some database operations, you would be suprised if you discovered it had gone into auto commit mode.
I wouldn't be surprised, actually. Can you tell exactly what's the behavior of a XA database connection in this circumstances?timfox wrote:
But that is exactly what you are expecting a jms xa connection to do.
Yes, this is what I expect.
None of us was able to produce spec paragraphs confirming or proving invalid our assumptions. How about trying the reference implementation? That would be the next logical step. -
20. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
"ovidiu.feodorov@jboss.com" wrote:
XASession is supposed to be transactional only if its XAResource is enrolled in a transaction.
Really? Can you point me to the place in the JMS spec that says this? Sounds like conjecture to me.
Although I will gladly concede if you can show me. -
21. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
"ovidiu.feodorov@jboss.com" wrote:
None of us was able to produce spec paragraphs confirming or proving invalid our assumptions.
I haven't made any assumptions or conjecture over and above what the JMS spec says should be the behaviour of an XASession.
I am merely saying that that the JBossMQ implementation adds *extra* semantics not specified in the spec. -
22. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
Here's the reference: JMS 1.1 spec Section 8.5:
"An application server controls the transactional assignment of an XASession by
obtaining its XAResource. It uses the XAResource to assign the session to a
distributed transaction, prepare and commit work on the transaction, and so
on." -
23. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
JMS 1.1 Specification Section 8.5 XA Session:
XASession provides access to what looks like a normal Session object and a javax.transaction.xa.XAResource object which controls the session?s transaction context. The functionality of XAResource closely resembles that defined by the standard X/Open XA Resource interface.
An application server controls the transactional assignment of an XASession by obtaining its XAResource. It uses the XAResource to assign the session to a distributed transaction, prepare and commit work on the transaction, and so on.
An XAResource provides some fairly sophisticated facilities for interleaving work on multiple transactions, recovering a list of transactions in progress, and so on. A JTA aware JMS provider must fully implement this functionality. This could be done by using the services of a database that supports XA, or a JMS provider may choose to implement this functionality from scratch. A client of the application server is given the XASession?s Session. Behind the scenes, the application server controls the transaction management of the underlying XASession.
It is important to note that a distributed transaction context does not flow with a message; that is, the receipt of the message cannot be part of the same
transaction that produced the message. This is the fundamental difference between messaging and synchronized processing. Message producers and
consumers use an alternative approach to reliability that is built upon a JMS provider ?s ability to supply a once-and-only-once message delivery guarantee.
To reiterate, the act of producing and/or consuming messages in a Session can be transactional. The act of producing and consuming a specific message across different sessions cannot.
This is the letter of the spec, and nothing else of substance is specified about XASession throughout. The phrase that I find interesting is the following: "An application server controls the transactional assignment of an XASession by obtaining its XAResource. It uses the XAResource to assign the session to a distributed transaction, prepare and commit work on the transaction, and so on."
Zooming again, "It uses the XAResource to assign the session to a distributed transaction [...]".
If there is no distributed transaction, then there can be no "prepare and commit work on the transaction", hence the session is non-transactional. -
24. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
Of course, this is a conclusion inferred from the specification, and not the specification itself, which seems to be incomplete in this area. So, given the circumstances, your guess is as good as mine, and that's why I say to go and see how the reference implementation behaves.
-
25. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
timfox wrote:
I am merely saying that that the JBossMQ implementation adds *extra* semantics not specified in the spec.
I agree with that, but with the observation that this "extra" hints at common sense. Of course, "common sense" may be different for different people :), so, again, let's see how the reference implementation behaves in this particular case. -
26. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
"ovidiu.feodorov@jboss.com" wrote:
If there is no distributed transaction, then there can be no "prepare and commit work on the transaction", hence the session is non-transactional.
That is one solution, but it isn't a logical necessity.
Other conforming implementations would be that messages (or acks) are stored up in the session, until work is started in a transaction, then the previous work done is transferred into the transaction.
In fact, a similar conversion already happens in certain situations:
See ResourceManager::convertTx(LocalTx anonXid, Xid xid) throws XAException
Which converts work done outside a global tx into work done inside the global tx.
As I said earlier in this thread, this is a religious argument and I don't think we'll find any conclusion in the JMS spec, since it is sparse at the best of times, especially the XA stuff. -
27. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
timfox wrote:
As I said earlier in this thread, this is a religious argument and I don't think we'll find any conclusion in the JMS spec, since it is sparse at the best of times, especially the XA stuff.
Right. Do you agree that analyzing the behavior of the reference implementation is the next step? -
28. Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
Regarding the reference implementation, based on the amount of effort Sun put into the specification in the xa area, personally I doubt whether they have specifically considered this edge case, so any results obtained from there may just be an accident of implementation.
I think we should be driven by what our customers expect the behaviour to be , i.e. we should make it work like JBoss MQ.
I am interested in what the RI says, but only as a curiousity.
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.