I just installed transactions 4.2.2 on server 4.0.4GA and now I am migrating my project to take advantage of the XA protocol with recovery. Prior to this, I was aware that that the XA implementation on JBoss was not really complete. I had my two resources, a database and my own JCA adapter, set up as local tx managed resources, even though methods in my session beans would access both in the same transaction. Without transaction logging there didn't seem much point in trying to do XA; a real failure would still screw things up.
I have run my unit tests on the new setup (with transaction 4.2.2) and found that they behave the same, where only one resource is hit. The tests which hit both resources fail. I plan to fix this in the near future by completing the XAResource implementation for my JCA wrapper.
Can someone confirm for me that this is happening because I am using two local tx resources, when I should be using XA resources? The error message I get does not make this obvious if it is in fact the case. Here is it is:
org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f57fffd:a7d:4569b0f6:4f status: 3 >)
... 64 more
Caused by: javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f57fffd:a7d:4569b0f6:4f status: 3 >
... 69 more
This should still be ok being that JBossTS AFAIK implements the strategy wherein a 1PC commit only resource can be used in tandem with other 2PC resources. If both resources are Local this also should not be a problem, or at the very least, you should not be getting the error that you are gettting below.
The error you are seeing below is in a failure to enlist which suggests a problem with the underlying resource. Have you tried this with JBossTM just to get an idea if the error is independent of TM implementation? If so, we can move this over to the JCA forum and take a look.
Just to ensure I am on the right wavelength with the terminology:
A "1PC commit only resource" is the same thing as a local tx resource?
A "2PC resource" is the same thing as an xa resource?
JBossTM means the in memory transaction manager?
JBossTS means the Arjuna ported transaction manager with recovery and full XA support?
Yes, I've tried my two local resources on JBossTM, individually and together, and it worked without complaint. I can succesfully use my JCA wrapper deployed as a local tx resource on JBossTS and the database local tx resource on JBossTS individually without any problem. Using both together (as local tx resources) in a single transaction causes the failure to enlist error with JBossTS. This doesn't seem at all unreasonable to me, as I am aware that you can't use the last resource gambit with more than one non-XA resource. I'm just not sure if the error I got is happening for that reason?
I'm about to upgrade the database resource to an XA one and see if the last resource gambit will work with my local only JCA before I plough ahead with completing its XAResource impl.
There were also two warnings prior to the exception stack trace:
[com.arjuna.ats.internal.jta.transaction.arjunacore.enliststarterror] [com.arjuna.ats.internal.jta.transaction.arjunacore.enliststarterror] TransactionImple.enlistResource - XAResource.start returned: XAException.XAER_PROTO for < 131075, 27, 25, 1--3f57fffd:a7d:4569b0f6:5c-3f57fffd:a7d:4569b0f6:62
org.jboss.resource.connectionmanager.JBossLocalXAException: Trying to start a new tx when old is not complete! old: < 131075, 27, 25, 1--3f57fffd:a7d:4569b0f6:4f-3f57fffd:a7d:4569b0f6:55
Weston, a speedy reply as always. Thanks. Do JBoss pay you to never sleep?
I am just sorry I can't be of more help. Yes you are right on the terms and also on the fact that this should not be an issue. Using a LocalTx enabled resource or resource(s) with an external TM, rather than leveraging the transaction management on the resource manager should not be an issue.
So, something is up!
In JBoss/JCA, LocalTx resources are wrapped in an XAResource implementation. As the TM drives the resource through the 2PC protocol the LocalXAResource simply calls the appropriate underlying being/commit/rollback transaction methods where appropriate. This is why you are seeing this guy:
in the logs. Basically the exception you are seeing indicates that a previous transaction still exists, or at the very least the Xid of the previous transaction is still around.
As a test can you try the following. Take two simple LocalTx datasources and drive them through a typical scenario. If this succeeds then we can at least narrow it down to taking a look at your adapter.
Also, can we turn TRACE on for the TxConnectionManager?
To make a long story short, I am not sure JBossTS is the issue. I believe it's probably either JBoss/JCA or the resource themselves.
JBossTS only allows a single 1PC resource to be enlisted in the transaction, LRCO makes little sense otherwise. It is likely that this is causing the failure to enlist.
Right, but technically because the way JCA works, the TM should see both LocalResources as XAResources because of the way we wrap LocalResources.
In my previous post I made sure to mention that the LRCO would only be in effect in the case that 1 one the resources was Local. In this particular case, even though both resources are Local it should still work.
Rupert, can you post he contents of your *-ds.xml file for your adapter?
It is my understanding that these XAResources are still tagged as a LastResource. If this is the case then we will recognise that and enforce the single 1PC restriction.
Even though the interface
is JBossTM specific? I did not know JBossTS honored this being that it was done for our own implementation prior to JBossTS integration.
We do, all my own work :-)
Figures. No wonder it's causing issues :-)
So, there you have it. JBossTM supports multiple LocalXAResources while JBossTS doesn't. Rupert...looks like you have a decision to make ;-)
Hey, not fair. We have to cope with recovery while JBossTM doesn't :-)
Recovery, as well as JBossTS, is overrated!
I prefer to not know about problems...just let them dissapear ;-)