11 Replies Latest reply on Jul 20, 2004 12:04 AM by adrian.brock

    Cleanup of ManagedConnection that's associated with a suspen

    drummer

      I’m seeing the following XA behavior running our RA in JBOSS 3.2.2:

      xa.start()
      Connection.close();
      xa.end(TMSUSPEND);
      ManagedConnection.cleanup()
      xa.end(TMSUCCESS);


      I wouldn’t expect to see the xa.end(TMSUCCESS) call after the ManagedConnection.cleanup. In effect, the cleanup call places the MC back into the pool for reuse; the RA should consider the MC to no longer be associated with the transaction. Additionally, cleaning up a MC that is associated with a suspended transaction branch seems like a bug. Besides this opens the door for some really interesting behavior if the MC is reused in another transaction before the xa_end(TMSUCCESS) call is made. Is the aforementioned behavior the intended behavior?

        • 1. Re: Cleanup of ManagedConnection that's associated with a su

          If you don't wish to support transaction interleaving you can use:

          <track-connection-by-tx/>
          


          But this is less efficient in terms of pooling. I suggest you separate your XAResource
          implementation from your ManagedConnection.



          • 2. Re: Cleanup of ManagedConnection that's associated with a su
            drummer

            My concerned is with the XAResource being involved in more than one transaction since the MC is placed into the connection pool before the XAResource.end(TMSUCCESS) call.

            For example, using the following settings for the -service.xml file:

            MinSize = 1
            MaxSize = 1
            BlockingTimeoutMillis = 5000
            IdleTimeoutMinutes = 0

            I create in EJB that has a method that simply executes the following steps:

            Connection = ConnectionFactory.getConnection(); // CF obtained in ejbCreate
            // do interaction stuff
            // connection.close();

            As part of the connection.close(), the transaction is suspended via XAResource.end(TMSUSPEND) and the MC is placed in the connection pool.

            The log shows the following for the acquisition and closing of a connection:

            2004-07-19 01:46:09,131 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] supplying new ManagedConnection: com.unisys.coms.connector.COMSManagedConnection@189cab
            2004-07-19 01:46:09,131 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Getting connection from pool [InUse/Available/Max]: [1/1/1]
            2004-07-19 01:46:09,131 TRACE [org.jboss.tm.TransactionImpl] enlistResource(): Entered, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//21, BranchQual=] status=STATUS_ACTIVE
            2004-07-19 01:46:09,131 TRACE [org.jboss.tm.TransactionImpl] startResource(XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//21, BranchQual=1]) entered: com.unisys.tip.TIPXAResource@1d5b945 flags=0
            2004-07-19 01:46:09,251 TRACE [org.jboss.tm.TransactionImpl] startResource(XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//21, BranchQual=1]) leaving: com.unisys.tip.TIPXAResource@1d5b945 flags=0


            2004-07-19 01:46:12,516 TRACE [org.jboss.tm.TransactionImpl] delistResource(): Entered, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//21, BranchQual=] status=STATUS_ACTIVE
            2004-07-19 01:46:12,516 TRACE [org.jboss.tm.TransactionImpl] endResource(XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//21, BranchQual=1]) entered: com.unisys.tip.TIPXAResource@1d5b945 flag=33554432
            2004-07-19 01:46:12,596 TRACE [org.jboss.tm.TransactionImpl] endResource(XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//21, BranchQual=1]) leaving: com.unisys.tip.TIPXAResource@1d5b945 flag=33554432
            2004-07-19 01:46:12,596 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] putting ManagedConnection back into pool

            IMHO, MC.cleanup should throw an exception here since the transaction, although suspended, is still active.

            Next the transaction is committed, but first XAResource.end(TMSUCCESS) is called. The XAResource.end(TMSUCCESS) is blocked waiting for an I/O to complete, thus the transaction never leaves the active state. The RA sees the xid as 0100000101100155534d562d42524f574e534b2f2f323131.

            The log shows the following:

            2004-07-19 01:46:12,666 TRACE [org.jboss.tm.TransactionImpl] Committing, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//21, BranchQual=], status=STATUS_ACTIVE
            2004-07-19 01:46:12,666 TRACE [org.jboss.tm.TransactionImpl] Before completion done, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//21, BranchQual=], status=STATUS_ACTIVE
            2004-07-19 01:46:12,666 TRACE [org.jboss.tm.TransactionImpl] endresources(0): state=2
            2004-07-19 01:46:12,666 TRACE [org.jboss.tm.TransactionImpl] endResource(XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//21, BranchQual=1]) entered: com.unisys.tip.TIPXAResource@1d5b945 flag=67108864


            Now, a second client invokes the EJB. The MC whose XAResource is already involved with an active transaction is pulled from the connection pool.

            The log shows the following:

            2004-07-19 01:48:45,206 DEBUG [org.apache.tomcat.util.threads.ThreadPool] Getting new thread data
            2004-07-19 01:48:45,206 TRACE [org.jboss.tm.TransactionImpl] Created new instance for tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//23, BranchQual=]
            2004-07-19 01:48:45,206 TRACE [org.jboss.tm.TxManager] began tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//23, BranchQual=]

            2004-07-19 01:48:45,216 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] supplying ManagedConnection from pool: com.unisys.coms.connector.COMSManagedConnection@189cab
            2004-07-19 01:48:45,216 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Getting connection from pool [InUse/Available/Max]: [1/1/1]


            A new transaction is started on the MC’s associated XAResource, the same XAResource that has a thread blocked in XAResource.end(TMSUCCESS). The RA sees the xid as 0100000101100155534d562d42524f574e534b2f2f323331


            The log shows the following:

            2004-07-19 01:48:45,216 TRACE [org.jboss.tm.TransactionImpl] enlistResource(): Entered, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//23, BranchQual=] status=STATUS_ACTIVE
            2004-07-19 01:48:45,216 TRACE [org.jboss.tm.TransactionImpl] startResource(XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//23, BranchQual=1]) entered: com.unisys.tip.TIPXAResource@1d5b945 flags=0

            2004-07-19 01:48:45,316 TRACE [org.jboss.tm.TransactionImpl] startResource(XidImpl [FormatId=257, GlobalId=USMV-BROWNSK//23, BranchQual=1]) leaving: com.unisys.tip.TIPXAResource@1d5b945 flags=0

            At this point, the RA can only throw an exception back to the TM, since the XAResource is already associated with an active transaction.

            Once the MC is placed back into the pool and because the MC has to maintain a 1-1 relationship with the XAResource (that is, MC.getXAResource must return the same XAResource instance), calling XAResource.end(TMSUCCESS) at this point can lead to the XAResource being involved in more than one transaction.

            As for the <track-connection-by-tx> attribute: it does work, but it is not compliant with the JCA specification

            • 3. Re: Cleanup of ManagedConnection that's associated with a su

              You didn't need to dump the logging, I know exactly how it works. :-)

              The MC only has to maintain a one-one relationship with the *active* XAResource,
              that is why TM_SUSPEND exists.

              JBossMQ handles transaction interleaving quite effectively, it allows fewer
              connections to be used for the same number of transactions.


              As for the <track-connection-by-tx> attribute: it does work, but it is not compliant with the JCA specification


              Configuration/deployment of the connection manager/pool isn't even in the jca spec
              so how can it be a compliance issue?

              • 4. Re: Cleanup of ManagedConnection that's associated with a su
                drummer

                First the apology:

                Configuration/deployment of the connection manager/pool isn't even in the jca spec so how can it be a compliance issue?


                The deployment/configuration of a connection manager/pool was never an issue, I simply misunderstood what the track-connection-by-tx attribute did. So, sorry about the earlier statement about not being compliant with the JCA specification, it does provided the expected behavior.

                You didn't need to dump the logging, I know exactly how it works. :-)


                Did not know.

                The MC only has to maintain a one-one relationship with the *active* XAResource,
                that is why TM_SUSPEND exists.


                Do you mean the current transaction context and not the XAResource? The JCA specification states the relationship should be with the same XAResource not the active XAResource. Section 6.3.2 of the JCA specification states the following:

                A resource adapter is responsible for maintaining a 1-1 relationship between the ManagedConnection and XAResource instances. Each time a ManagedConnection.getXAResource method is called, the same XAResource instance has to be returned.

                JBossMQ handles transaction interleaving quite effectively, it allows fewer
                connections to be used for the same number of transactions.


                I do not have a problem with transaction interleaving, but with the branch’s transaction association and when the MC is placed in the connection pool. In the example I presented, the association between the MC and the current transaction context is only suspended. Thus, a new transaction context cannot be associated with the XAResource. From section 3.4.4 of the JTA specification, it states the following:

                Global transactions are associated with a transactional resource via the XAResource.start method, and disassociated from the resource via the XAResource.end method. The resource adapter is responsible for internally maintaining an association between the resource connection object and the XAResource object. At any given time, a connection is associated with a single transaction or it is not associated with any transaction at all.

                The last sentence is key, because in my example the XAResource.end(TMSUCCESS) call has not returned before the second client comes along - thus the transaction association is still in a suspended state; Table 1 - Transaction Association of the JTA specification shows that XAResource.start() cannot be called on a branch whose transaction association has been suspended. XAResource.start(TMRESUME|TMJOIN) may be called on a branch whose transaction association has been suspended, but returning the MC to the pool implies that MC is not associated with any transaction - I would expect XAResource.end(TMSUCCESS) to be invoked before the MC is returned to the connection pool.

                I am probably missing a step somewhere, I would like to take advantage of JBOSS's transaction interleaving implementation, but I have concerns with transaction association, who is doing work on what transaction, and compatibility issues with other application server. Basically, I need to do more testing. Anyway, the track-connection-by-tx attribute provides what I need. Thanks for your time it is much appreciated. Now, if we only had recovery...


                • 5. Re: Cleanup of ManagedConnection that's associated with a su

                  Before we discuss this further, you should be careful reading the specs.
                  Especially the JTA and JTS specs.

                  Most people who have to implement them find them contradictory and incomplete.

                  In fact, they are largely meant as wrappers for the Corba specs, which until
                  recently had the same problems, but they are getting better (the same cannot
                  be said for the java specs.

                  You also have to remember that they specify the minimal behaviour not what is
                  possible.

                  • 6. Re: Cleanup of ManagedConnection that's associated with a su

                    Nothing about what you have said contradicts what JBoss does.

                    If you want to get the basic, look at section 3.4.6 in the JTA spec,
                    although it only deals with the XAResource part.

                    To get a more concrete idea, suppose you have a transaction that
                    1) Sends a jms message
                    2) Does 3 minutes of intensive db work

                    It would be a waste of resources to lock out the jms connection during that
                    3 minutes of db work. Instead, the jms connection can be closed/returned to the pool
                    then somebody else can use it to do jms work.
                    Once the db work is complete, the xid is committed.


                    • 7. Re: Cleanup of ManagedConnection that's associated with a su

                      You do not have to implement transaction interleaving.
                      e.g. OracleXA does not - but then it hardly follows the spec anyway :-)

                      JBoss has the "get out" track-connection-by-tx.

                      This is also used implicitly for things like local database connections, i.e. plain jdbc,
                      which has no notion of interleaving of transactions.

                      • 8. Re: Cleanup of ManagedConnection that's associated with a su

                        P.S. I don't follow your point about table 1 in the JTA spec.

                        Maybe I read it differently?

                        Be careful with the "Associated"/"Association Suspended" and note
                        where it says XAResource.end rather than XAResource.end(SUCCESS)

                        • 9. Re: Cleanup of ManagedConnection that's associated with a su
                          drummer

                          You are probably right, but I have not seen it yet at least not completely.

                          JTA section 3.4.6 fails to specify the flag setting - it simply says xares.end(xid1); additionally, it does not talk about transaction associations. I am concerned with the responsibilities of the RA. Again, from section 3.4.4 is the following:

                          ...The resource adapter is responsible for internally maintaining an association between the resource connection object and the XAResource object. At any given time, a connection is associated with a single transaction or it is not associated with any transaction at all.

                          Again, I am probably missing a step or two, so until I have done some additionally testing there is not a need to discuss it any further. I do understand what it is you are trying to accomplish (or have accomplished), I just need to give it some more thought. Once again thanks for your help.

                          • 10. Re: Cleanup of ManagedConnection that's associated with a su
                            drummer

                             

                            P.S. I don't follow your point about table 1 in the JTA spec.

                            Maybe I read it differently?

                            Be careful with the "Associated"/"Association Suspended" and note
                            where it says XAResource.end rather than XAResource.end(SUCCESS)


                            Within the EJB method:

                            1) Connection.close is invoked

                            2) The RA sees xa_end(TMSUSPEND) - the transaction association state is now T2. Control is returned to the caller.

                            3) After the EJB method exits, XAResource.end(TMSUCCESS) is called, but does not return control to the caller. The RA continues to see the state as T2

                            4) start(TMNOFLAGS) is invoked on the same XAResource on behalf of the second client. Table 1 states that start(TMNOFLAGS) is not allowed on a suspended transaction (transaction association state T2). The logs show this being done for the second client.

                            • 11. Re: Cleanup of ManagedConnection that's associated with a su

                              I probably mislead you a bit before with talk about *active XAResource",
                              I can be a bit loose in my terminolgy.

                              It is probably best to think of it as session state per transaction: with
                              MC - XAResource -< Session
                              - == one-one
                              -< == one-many

                              i.e. the XAResource has a map of xid to session state.

                              The key part is that only one xid/session can be active (associated) at any given time.