[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
by timfox
"ovidiu.feodorov(a)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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968774#3968774
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968774
18 years, 4 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi
by ovidiu.feodorov@jboss.com
JMS 1.1 Specification Section 8.5 XA Session:
anonymous wrote :
| 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.
| anonymous wrote :
| |
| | 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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968770#3968770
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968770
18 years, 4 months