3 Replies Latest reply on Dec 22, 2006 4:53 PM by Jeff DeLong

    Correct XA behaviour on closing a connection

    Tim Fox Master

      If an XASession, created from an XAConnection does some work in a global transaction, the transaction gets prepared, then the connection gets explicitly closed (invoke of close()) before the transaction has been committed or rolled back by the transaction manager, what is the correct behaviour?

      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?

        • 1. Re: Correct XA behaviour on closing a connection and JCA
          Tim Fox Master

          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 Master

             

            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
              Jeff DeLong Master

              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.