rollback not called in enlisted XA resource| JBoss.org Content Archive (Read Only)

15. Re: rollback not called in enlisted XA resource

neilcurzon Mar 28, 2007 11:35 AM (in response to neilcurzon)

"mark.little@jboss.com" wrote:
Can you turn on debugging for JBossTS, then we can see the flow of messages and method invocations?

"weston.price@jboss.com" wrote:
And trace at the JBossJCA layer as well. There is already an entry in your log4j.xml file to do this, simly uncomment it.

Could you please point us towards the files and settings we need to change?

Thanks.

16. Re: rollback not called in enlisted XA resource

weston.price Mar 28, 2007 11:41 AM (in response to neilcurzon)

Hi,
For JCA have a look at the following:

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=59031

Note, disregard the section on the TM, this is done differently with JBossTS which I am sure Mark and/or Kevin can describe.

17. Re: rollback not called in enlisted XA resource

marklittle Mar 28, 2007 11:53 AM (in response to neilcurzon)

http://labs.jboss.com/portal/jbosstm/docs/4.2.2/manuals/html/core/AdministrationGuide.html

18. Re: rollback not called in enlisted XA resource

neilcurzon Mar 28, 2007 1:39 PM (in response to neilcurzon)

"mark.little@jboss.com" wrote:
http://labs.jboss.com/portal/jbosstm/docs/4.2.2/manuals/html/core/AdministrationGuide.html

I'm having some difficulty understanding this document.

Messages describing the start and the periodical behavior made by the RecoveryManager are output using the INFO level. If other debug tracing is wanted, the finer debugging level should be set appropriately. For instance, the following configuration, in the CommonLogging.xml, enables all debug messages related to the Crash Recovery protocol and issued by the ArjunaCore module.

<!-- Common logging related properties. -->

 <property

 name="com.arjuna.common.util.logging.DebugLevel"

 value="0x00000000"/>

 <property
 name="com.arjuna.common.util.logging.FacilityLevel"

 value="0xffffffff"/>

 <property
 name="com.arjuna.common.util.logging.VisibilityLevel"

 value="0xffffffff"/>

I don't see any settings that refer to the Crash Recovery protocol in this example, so I don't understand how to extend this to enable "debugging for JBossTS". It refers to a CommonLogging.xml file which I can't find in my jboss instances (which is 4.0.3SP1), but it seems that the relevant settings are in jbossjts-properties.xml. The portion existing in that file already looks like the example in this guide:

 <properties name="common">
 <!-- CLF 2.0 properties -->
 <property name="com.arjuna.common.util.logging.DebugLevel"
 type="System" value="0x00000000"/>
 <property name="com.arjuna.common.util.logging.FacilityLevel"
 type="System" value="0xffffffff"/>
 <property name="com.arjuna.common.util.logging.VisibilityLevel"
 type="System" value="0xffffffff"/>
 <property name="com.arjuna.common.util.logger" type="System" value="log4j"/>
 </properties>

Does this look correct, or is there some other setting I should change?

19. Re: rollback not called in enlisted XA resource

neilcurzon Mar 28, 2007 2:55 PM (in response to neilcurzon)

We've created a simplified example that does it a little differently. A->B->C, all different EJBs installed into separate instances of JBoss on different machines. A, B, and C enlist dummy XA resources in the transaction that just print out the method names and parameter values. C sets the transaction to rollback only.-

We see better behavior, but still not necessarily expected. The resources enrolled on A and B see start, end, prepare, rollback. The resource enrolled on C sees start, end, rollback. Prepare is never called.

We're analyzing the differences between our actual code and the simple test case. Are we correct that prepare should be called on C's XA resource in this case?

20. Re: rollback not called in enlisted XA resource

marklittle Mar 28, 2007 5:09 PM (in response to neilcurzon)

"neilcurzon" wrote:
We've created a simplified example that does it a little differently. A->B->C, all different EJBs installed into separate instances of JBoss on different machines. A, B, and C enlist dummy XA resources in the transaction that just print out the method names and parameter values. C sets the transaction to rollback only.-

We see better behavior, but still not necessarily expected. The resources enrolled on A and B see start, end, prepare, rollback. The resource enrolled on C sees start, end, rollback. Prepare is never called.

We're analyzing the differences between our actual code and the simple test case. Are we correct that prepare should be called on C's XA resource in this case?

No, you shouldn't see prepare called on C if it set the transaction into rollback-only mode. A prepare message will be sent to C from the coordinator, but the subordinate coordinator residing in C will know that it (and hence the global transaction) is really in rollback-only mode and turn the incoming prepare message into a rollback and subsequently return VoteRollback to the root coordinator.

BTW, I'm just about to go on vacation for a week, so apologies in advance if responses are delayed.

21. Re: rollback not called in enlisted XA resource

marklittle Mar 28, 2007 5:13 PM (in response to neilcurzon)

"neilcurzon" wrote:

 <properties name="common">
 <!-- CLF 2.0 properties -->
 <property name="com.arjuna.common.util.logging.DebugLevel"
 type="System" value="0x00000000"/>
 <property name="com.arjuna.common.util.logging.FacilityLevel"
 type="System" value="0xffffffff"/>
 <property name="com.arjuna.common.util.logging.VisibilityLevel"
 type="System" value="0xffffffff"/>
 <property name="com.arjuna.common.util.logger" type="System" value="log4j"/>
 </properties>

Does this look correct, or is there some other setting I should change?

Set DebugLevel to 0xffffffff and you'll get debugging for every component within JBossTS. You can fine tune that to different aspects, but until you know what's working and what's not, it may be better to see everything.

BTW, the docs are slightly out-of-date and I've created a task to fix them. http://jira.jboss.com/jira/browse/JBTM-209

22. Re: rollback not called in enlisted XA resource

neilcurzon Mar 30, 2007 11:27 AM (in response to neilcurzon)

We've reproduced some unexpected behavior with a simplified test case.

A->B, two separate EJBs on different instances of JBoss on separate machines that enlist dummy XA resources in the transaction. If B sets the transaction to rollback only in the session context, we see that if the original invoker of A (call it U) calls rollback, B's XA resource never sees rollback called. If U calls commit, B's XA resource DOES see rollback called.

If B does not set the transaction to rollback only, then a rollback from U still causes B's XA resource to see rollback

Are we correct that this behavior is unexpected? If so, would it be useful to post this test case?

23. Re: rollback not called in enlisted XA resource

kconner Mar 30, 2007 11:34 AM (in response to neilcurzon)

Please send your test case directly to me and I will have a look at it.

24. Re: rollback not called in enlisted XA resource

neilcurzon Apr 5, 2007 2:22 PM (in response to neilcurzon)

"Kevin.Conner@jboss.com" wrote:
Please send your test case directly to me and I will have a look at it.

Thanks for accepting our test case. Any updates?

We've discovered another unexpected behavior with JBoss JTS.

A->B->C, three different EJBs on three different instances of JBoss on separate machines. A, B, and C all enlist dummy XA resources in the transaction. A calls B and then B calls C.

Case 1: C sets the transaction to rollback only in session context.
Result 1: XA Resources at A, B and C all see rollback called. (expected)

Case 2: B and C set the transaction to rollback only in session context.
Result 2: XA Resources at A and B see rollback called. C's XA resource never sees rollback. (expected all to have rollback called).

Are we correct in our expectations? Would this test case be useful to submit?

25. Re: rollback not called in enlisted XA resource

neilcurzon Apr 5, 2007 3:06 PM (in response to neilcurzon)

New test:

Case 3: B sets the transaction rollback only
Result 3: A, B and C all see rollback called on their XA resources (expected)

26. Re: rollback not called in enlisted XA resource

kconner Apr 6, 2007 4:35 AM (in response to neilcurzon)

Hiya Neil.

Please see the following JIRA issue.

This issue fixes the case where you have two servers and the second calls setRollbackOnly for a rollback.

I am on holiday until the 17th, starting from today, but I can look at your second issue when I return. We are close to releasing 4.2.3GA so I will try and get this fix included for that release.

27. Re: rollback not called in enlisted XA resource

kconner Apr 6, 2007 4:45 AM (in response to neilcurzon)

Hiya Neil.

One more thing. Thanks for providing such a good testcase and explanation of the problem. :-)

Kev