-
1. Re: Cleanup of ManagedConnection that's associated with a su
adrian.brock Jul 9, 2004 11:06 PM (in response to drummer)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 Jul 19, 2004 4:00 PM (in response to 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
adrian.brock Jul 19, 2004 4:24 PM (in response to drummer)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 Jul 19, 2004 9:56 PM (in response to 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
adrian.brock Jul 19, 2004 10:32 PM (in response to drummer)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
adrian.brock Jul 19, 2004 10:39 PM (in response to drummer)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
adrian.brock Jul 19, 2004 10:43 PM (in response to drummer)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
adrian.brock Jul 19, 2004 10:50 PM (in response to 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) -
9. Re: Cleanup of ManagedConnection that's associated with a su
drummer Jul 19, 2004 11:52 PM (in response to 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 Jul 20, 2004 12:01 AM (in response to 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
adrian.brock Jul 20, 2004 12:04 AM (in response to drummer)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.