-
1. Re: Correct XA behaviour on closing a connection and JCA
timfox Dec 21, 2006 6:46 AM (in response to timfox)The spec seems to be completely silent on this.
I would be interested to know how JCA treats this. Does the JCA layer ever close connections that have XASessions that are still enlisted in a global tx, or does it never do this.
Problem, is, even if the JCA layer never does this, Jo dumb user who is using the XAConnection might, and we need to know what to do when he closes that connection that has sessions still enlisted.
For now, I will treat explicitly closing a connection after prepare has been called but before commit/rollback has been called the same as a server crash, i.e. the resource manager retains the prepared state so it's available to any subsequent recover() calls. -
2. Re: Correct XA behaviour on closing a connection
ovidiu.feodorov Dec 22, 2006 3:53 PM (in response to timfox)Tim wrote:
Should the messaging resource manager, locally roll back (remove) the prepared state for that connection? Or it should it retain it, in the hope that the transaction manager will eventually call rollback or commit by obtaining an xaresource by recover() for instance?
Second option (?)
After all, the work is already part of the global transaction state, irrespective of the fact that connection (session) is closed or not.Tim wrote:
I would be interested to know how JCA treats this. Does the JCA layer ever close connections that have XASessions that are still enlisted in a global tx, or does it never do this.
Easy to find out. Model it ... -
3. Re: Correct XA behaviour on closing a connection
jeffdelong Dec 22, 2006 4:53 PM (in response to timfox)I seem to recall having a similar issue using the WebSphere 5.1 Embedded JMS Server. It has been about 3 years or more so I am not crystal clear on all the details. I has a stateless session bean that I used to send JMS messages from a third party process engine as part of a global transaction. I needed to close the session after each message was sent because the WebSphere Embedded JMS Server was not thread safe, i.e. if one thread sent a message on the same session as a second message on another thread, the JMS server might get confused and throw an exception. But when I closed the session in the finally clause, the message did not get sent, because the transaction had not been commited.
The solution in this case was to make the JMS session an instance variable and close it the next time the session bean method was invoked, and then create a new session each time.
I guess my point is the "Jo dumb user" may need to close the session, to conserve resources or some other reason but has little control / knowledge of when the global transaction is going to commit.
jBPM and hibernate have a similar issue. jBPM would typically tell hibernate to close the hibernate session when the jbpmContext is closed. Fortunately jbpm has a configuration option that can turn off this behavior in a managed environment. HIbernate also has configuration options to auto close session after transaction commits.
It might be nice if there were a JMS server configuration option to say 'defer closing sessions until transaction commits' or something similar. That way the choice can be specified by the user, although I would vote to make this the default, since I think that most often with a user closes the session, they still expect the message to be sent.