1 2 Previous Next 22 Replies Latest reply on Apr 21, 2010 9:26 AM by jesper.pedersen Go to original post
      • 15. Re: HornetQ RA integration

        Tim Fox wrote:

         

        Adrian,

         

        So you're saying it's correct for a JCA impl to call

         

        getManagedConnection()

         

        then

         

        managedConnection.getXAResource()

         

        and then never enlist the resource in a tx, and expect the managed connection to behave as non transacted?

         

        I can't see this requirement in the JCA spec anyway, but I will defer to your better knowledge of JCA.

        Why do you think that is a correct assumption?

         

        The managed connections are pooled, so you've got no idea whether the connection is enlisted from one check out of the

        connection from the pool to the next unless you track it yourself in the ManagedConnection/XAResource calls.

         

        All your assumption does (including your wrapper workaround) is defer the failure to the case when

        for the same ManagedConnection it does:

         

        Request1: Is in a tx so use an XAConnection

        Request2: Not in a tx - oops still tries to use an XAConnection for non xa stuff.

         

        That is unless you back the ManagedConnection with two real connections/sessions?

         

        Anyway, although not exactly on topic, I remember arguing about this line in the JCA 1.6 spec review

        See 7.10.1 Transaction Scenarios Requirements

        "

        Note that both
        LocalTransaction and XATransaction resource adapters support local
        transactions. and they are both referred to as “local transaction capable” resource
        adapters in the section below.

        "

        We came to conclusion that this statement (from an older version of the spec) says

        that you can deploy a rar declared as XATransaction in local-tx mode at the connection factory level.

         

        But it could also be taken to require the behaviour we are discussing?

        • 16. Re: HornetQ RA integration

          Tim Fox wrote:

          If that's not correct, I find it odd. However our impl should work in either case now, since Jeff has created a proxy around the real XAResource which switches between a non transacted and an XA session behind the scenes depending on whether the resource has been enlisted or not.

          I guess we could implement that for you with a slight tweak to the TxConnectionManager.

          i.e. if you configure

          <no-tx-seperate-pools/> - an old workaround for Oracle

          on the tx-connection-factory we use the LocalXAResource rather than invoking getXAResource()

          when the request is outside a JTA transaction at initial construction of the ManagedConnection,

          regardless of whether it says <xa-transaction/>

           

          That way you'll have two seperate pools for the different types of requests.

          In one pool getXAResource() will have been invoked, in the other it won't.

           

          Of course, other JCA implementations probably don't have that feature,

          so you'll still have problems with them. ;-)

          • 17. Re: HornetQ RA integration
            timfox

            Adrian Brock wrote:


            Why do you think that is a correct assumption?

             

            The managed connections are pooled, so you've got no idea whether the connection is enlisted from one check out of the

            connection from the pool to the next unless you track it yourself in the ManagedConnection/XAResource calls.

             

            All your assumption does (including your wrapper workaround) is defer the failure to the case when

            for the same ManagedConnection it does:

             

            Request1: Is in a tx so use an XAConnection

            Request2: Not in a tx - oops still tries to use an XAConnection for non xa stuff.

             

            That is unless you back the ManagedConnection with two real connections/sessions?

             


            Yeah, that's the plan. E.g. ManagedConnection potentially maintains two refs - one to a non transacted session and one to an XA session.

             

            Personally I don't like the idea of an XA session behaving as non transacted when not enlisted. To me either it's an XA session or not.

             

            I'm thinking - do other XA capable EIS XA connections default to non transacted when not enlisted? My hunch is no, since this doesn't seem to be mandated anywhere, and some (e.g. databases) XA functionality probably existed long before JCA.

             

            If that's the case, some kind of jiggery pokery like we're doing with maintaining two refs, is probably done by them inside their own JCA adaptors in order to satisfy the semantics that JCA expects.

            • 18. Re: HornetQ RA integration
              jmesnil

              One more question about HornetQ RA,

               

              We argued with tim on the number of session we must keep in our ManagedConnection to handle all use cases (esp. doing JMS work using a non-enlisted XA Session).

               

              Currently, we have 2 sessions:

              - 1 XA Session

              - 1 regular JMS session which is transacted or not depending on the ConnectionRequestInfo

               

              Tim argues that we need 3 sessions:

              - 1 XA Session (to be used when doing work in a enlisted XA tx)

              - 1 transacted session (to be used when doing work in a local tx)

              - 1 non-transacted session (to be used when doing work from a XA Resource which is not enlisted)

               

              What do you think about this?

              Does the connection pool should have partitioned the managed connections based on their transaction types (and 2 sessions are ok)

              or should we have 3 sessions and return the correct one ourselves?

              • 19. Re: HornetQ RA integration
                timfox

                To clarify, this is the problem we have.

                 

                AS gets a managed connection and calls getLocalTransaction(), this results internally in the RA creating a transacted local session.

                 

                The user does work with that connection, then finished, it gets returned to the pool.

                 

                Next user wants an XA connection, AS gets the same cached managed connection, getXAResource is called, but the resource is never enlisted in a tx.

                 

                This causes us to use the local  transacted session we cached earlier on the connection, but it's transacted, and the behaviour we require is an XA session behaves as non transacted non XA session when not enlisted.

                • 20. Re: HornetQ RA integration
                  jesper.pedersen

                  You are looking for the case where the ManagedConnection is used in a LocalTransaction, then put back into the pool, then retrieved but not enlisted in a transaction, correct ?

                   

                  The comments in

                   

                  org.jboss.resource.adapter.jms.JmsManagedConnection
                  

                   

                  provides some insight to this case inside an application server:

                   

                  * <p>From the JMS tutorial:
                  *    "When you create a session in an enterprise bean, the container ignores
                  *    the arguments you specify, because it manages all transactional
                  *    properties for enterprise beans."
                  *
                  * <p>And further:
                  *    "You do not specify a message acknowledgment mode when you create a
                  *    message-driven bean that uses container-managed transactions. The
                  *    container handles acknowledgment automatically."
                  

                   

                  So the above case would be out-of-scope.

                  • 21. Re: HornetQ RA integration
                    timfox

                    Jesper, I don't follow the connection between the question we are posing at the spec. excerpt that you cite. Can you elaborate?

                     

                    Let me summarise the problem again, it's in two parts:

                     

                    We're considering the case, where a managed connection has been used as part of a local transaction, then that's completed and it's returned to the pool.

                     

                    The same connection is then retrieved from the pool, getXAResource is called, but it's not enlisted in any JTA tx.

                     

                    The user then sends some messages using this connection. (There is actually a TCK test that tests this)

                     

                    How should that connection behave?

                     

                    According to the previous discussion it should behave as a non transacted session, however that was for the case when the connection was previously used as part of another JTA tx, in this case the connection has been used as part of a local tx.

                     

                    In this case should the connection also act as a non transacted session, like in the XA case?

                    • 22. Re: HornetQ RA integration
                      jesper.pedersen

                      We're considering the case, where a managed connection has been used as part of a local transaction, then that's completed and it's returned to the pool.

                      In this the managed connection should reset to its default state through the ManagedConnection.close() method. See 7.10 in JCA 1.6.

                       

                      The same connection is then retrieved from the pool, getXAResource is called, but it's not enlisted in any JTA tx.

                       

                      The user then sends some messages using this connection. (There is actually a TCK test that tests this)

                       

                      How should that connection behave?

                      A transactional resource adapter used outside of a transaction must behave as auto-commit = true. See 7.15.1.1 in JCA 1.6.

                       

                      According to the previous discussion it should behave as a non transacted session, however that was for the case when the connection was previously used as part of another JTA tx, in this case the connection has been used as part of a local tx.

                      Could you expand on this "previously used" case ?

                      1 2 Previous Next