XTS/bridge: two diff. TXs on same thread?| JBoss.org Content Archive (Read Only)

15. Re: XTS/bridge: two diff. TXs on same thread?

ruthbd May 29, 2008 9:59 AM (in response to ruthbd)

"jhalliday" wrote:
Definitely something fishy going on there. Bundle up a test case and send it my way, I'll take a look when I get time.

So, back to my non-working project code. I set the propagation attribute on the @Transactional to Propagation.MANDATORY (existing transaction required), and as expected, an exception is thrown because an existing transaction wasn't found.

Any recommendations on where the best place to put some breakpoints would be? If I break after InboundBridge#start(), I should be able to interrogate if a Tx exists on the thread, right? What's the best way of doing that?

Thanks for all the help so far!

16. Re: XTS/bridge: two diff. TXs on same thread?

jhalliday May 29, 2008 10:07 AM (in response to ruthbd)

> If I break after InboundBridge#start(), I should be able to interrogate if a Tx exists on the thread, right? What's the best way of doing that?

TransactionManager.transactionManager().getTransaction()

17. Re: XTS/bridge: two diff. TXs on same thread?

ruthbd May 29, 2008 10:18 AM (in response to ruthbd)

Alright, immediately following InboundBridge#start():

(com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple) TransactionImple < jca-subordinate, BasicAction: a413888:cb8:483eb2ad:8 status: ActionStatus.RUNNING >

Immediately before Spring's TransactionInterceptor calls getTransaction():

(com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple) TransactionImple < ac, BasicAction: a413888:cb8:483eb2ad:8 status: ActionStatus.COMMITTING >

So, I have to admit, this means nothing to me, but Jonathan ... maybe this sheds some light?

18. Re: XTS/bridge: two diff. TXs on same thread?

ruthbd May 29, 2008 10:29 AM (in response to ruthbd)

Strange ... if I resubmit my WS request, and break immediately after InboundBridge#start() (again), I get this now:

(com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple) TransactionImple < ac, BasicAction: a413888:cb8:483eb2ad:8 status: ActionStatus.COMMITTING >

What's up with that?! This almost looks like something isn't getting cleaned up right (very likely the fault of my app ... probably a config that's screwy?!)

19. Re: XTS/bridge: two diff. TXs on same thread?

jhalliday May 29, 2008 10:29 AM (in response to ruthbd)

The first of those is ok, the second one is not. What code lies between?

20. Re: XTS/bridge: two diff. TXs on same thread?

ruthbd May 29, 2008 10:32 AM (in response to ruthbd)

Well, we're using Spring + XFire, right? So, InboundBridge#start() is called from an "InHandler", called from XFire's Handler pipeline. When that pipeline is exhausted, XFire invokes the ServiceBean, which is my code with the @Transactional annotation. XFire in fact invokes a proxy object, which passes through the TransactionInterceptor, which in turn calls my bean.

Obviously something more is going on, but heck if I know where to put my finger ...

21. Re: XTS/bridge: two diff. TXs on same thread?

jhalliday May 29, 2008 10:54 AM (in response to ruthbd)

*cough* test case *cough*

Preferably one that actually exhibits the problem :-)

22. Re: XTS/bridge: two diff. TXs on same thread?

ruthbd May 29, 2008 10:55 AM (in response to ruthbd)

"jhalliday" wrote:
*cough* test case *cough*

Preferably one that actually exhibits the problem :-)

Indeed. Easier said than done! :(

23. Re: XTS/bridge: two diff. TXs on same thread?

jhalliday May 29, 2008 10:57 AM (in response to ruthbd)

yeah, usually takes longer to write the test case than to fix the issue.

24. Re: XTS/bridge: two diff. TXs on same thread?

ruthbd May 29, 2008 10:58 AM (in response to ruthbd)

"jhalliday" wrote:
yeah, usually takes longer to write the test case than to fix the issue.

Right. If I could figure out which *broken* part to replicate from my project into a test case ... hmmm ... I could probably fix it! ;-)

25. Re: XTS/bridge: two diff. TXs on same thread?

jhalliday May 29, 2008 11:02 AM (in response to ruthbd)

Replicate everything, then start throwing bits out until it starts working or gets small enough not to scare me off.

26. Re: XTS/bridge: two diff. TXs on same thread?

ruthbd May 29, 2008 11:49 AM (in response to ruthbd)

"jhalliday" wrote:
Replicate everything, then start throwing bits out until it starts working or gets small enough not to scare me off.

OK, I took another look at the XFire configuration (it has had issues in the past w/ confounding Tx demarcation) and removed some pieces that seemed unnecessary.

Now I am seeing a slightly different behavior. When I run

com.arjuna.ats.jta.TransactionManager.transactionManager().getTransaction()

after InboundBridge#start(), I get the "good" output ...

(com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple) TransactionImple < jca-subordinate, BasicAction: a413888:404:483ecc58:8 status: ActionStatus.RUNNING >

When I run it before the TransactionInterceptor calls getTransaction(), I also get the "good" output now ... (consistently, even ..)

(com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple) TransactionImple < jca-subordinate, BasicAction: a413888:404:483ecc58:8 status: ActionStatus.RUNNING >

But, when the TransactionInterceptor actually runs through, its still throwing an exception with Propagation.MANDATORY, because it claims it doesn't have an existing transaction.

So ... I ran the following:

((javax.transaction.TransactionManager) new javax.naming.InitialContext().lookup("java:TransactionManager")).getTransaction()

This returned null ... at the same exact point where the above returned a "good" result ...

I verified that nothing else was amiss ... the following execution

new javax.naming.InitialContext().lookup("java:TransactionManager")

returns

(com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate) com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@6fc757

So ... this isn't right, is it?! Why is getTransaction() from the TxM in JNDI returning null?!

27. Re: XTS/bridge: two diff. TXs on same thread?

jhalliday May 29, 2008 11:58 AM (in response to ruthbd)

I'm going to take a wild guess (I do that a lot when I don't have a test case) and say you have a classloader problem. You probably get one TransactionManager for the bridge and a different one for the app server. If the artefacts you are deploying include jbossjta.jar or jbossts-common.jar try removing them, as they are provided by the app server.

28. Re: XTS/bridge: two diff. TXs on same thread?

ruthbd May 29, 2008 12:00 PM (in response to ruthbd)

"jhalliday" wrote:
I'm going to take a wild guess (I do that a lot when I don't have a test case) and say you have a classloader problem. You probably get one TransactionManager for the bridge and a different one for the app server. If the artefacts you are deploying include jbossjta.jar or jbossts-common.jar try removing them, as they are provided by the app server.

I like wild guesses. We've had our share or classloader issues, so this seems entirely feasible! ;-)

29. Re: XTS/bridge: two diff. TXs on same thread?

ruthbd May 29, 2008 12:15 PM (in response to ruthbd)

I think we can mark this one _solved_. Had a copy of jbossjts.jar && jbossts-common.jar.

Here's the kicker ... (and to redeem myself as not a total idiot) ... my test case (the one we created with Paul R. back in Oct. '07) that is working currently ... also has these pieces deployed in the .ear!

My guess is that even though they're in *that* .ear, they aren't specifically defined as a module in application.xml (they _are_ in my main project, as the Ant script defines them in application.xml automatically), so barring an explicit manifest-classpath, JBoss is deferring to the container JARs and ignoring the .ear JARs in my test case.

More than meets the eye ...

[and as my son would say ... "Transformers, rollout!"] ;-)