I'm curious as to why you would spend your time trying to make a psuedo xa driver work when it won't provide you different semantics than the jdbc 1 driver. Am I missing something?
Can you provide more info on how you got this sequence of calls to occur? Is Postgres handing out the same XAResource from more than one connection?
I assume you are using the Minerva xa wrapper. I'd appreciate it if you would try the new wrapper I committed to jboss 4 (cvs head) yesterday. So far it is untested, but if it is a problem with the wrapper I would rather fix the new version.
There are actually several reason for using it:
- To get rid of the warning whenever I use JMS and CMPs in the same transaction (though I'm betting there are ways to disable it)
- 2pc is on the list of post Pg 7.3 items to address and I'd like to be familiar with the obsoleted Pg JDBC XA code and JDBC XA in general when it comes time that Pg can actually support it (this is *not* Minerva, but code in the Pg JDBC tree)
- Minerva source is difficult to find... in fact the only location I found it was in the Attic of the JBoss tree.
- When I looked at the Minerva commit function scared me... why is the onePhase variable named twoPhase???
- Minerva requires that commit be called *before* another transaction starts... this can be supported in JDBC 1.0.
- I have yet to find a working Minerva wrapper configuration or documentation for JBoss 3.0.x
If you have a jar file for the JBoss 4 XA wrapper class that I can deploy into JBoss 3.0.x I would be happy to try it.
As far as getting a repeatable case of the strange start behavior, I'll have to get back to you on that as I'll need to come up with a small test case but I don't believe I'm doing anything unusual... just JMS, MessageDrivenBean, and EJB.
It is also weird the way JCA uses JOIN semantics though I don't think it is technically a spec violation...
XAResource A: Xid 1 JOIN
XAResource A: Xid 1 SUSPEND
XAResource A: Xid 2 JOIN
XAResource A: Xid 2 SUSPEND
XAResource A: Xid 1 JOIN
XAResource A: Xid 1 TMSUCCESS
Since XAResource A has "seen" Xid 1, I would expect the second JOIN to be a RESUME. But again, I don't think the JTA spec is clear on the definition of "seen" so this is likely perfectly valid.
Good and Bad news... the Firebird XA driver shows that this behavior is not limited to the PostgreSQL pseudo-XA hack.
19:47:58,564 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257, GlobalId=job.ba.macykids.net//812, BranchQual=] errorCode=XA_UNKNOWN(0)
javax.transaction.xa.XAException: start called with transaction associated