JBossDeveloper

So ... AppServerJDBCXARecovery ... in jbossts.properties is obsolete in EAP 5.1.0 and

.. MessagingXAResourceRecovery... is still required?

yup, that should be the case. It's easy to tell - the deprecated version of AppServerJDBCXARecovery will log "WARN: no longer required, see JBTM-756" or something similar. If you see that in the logs you can safely delete the AppServerJDBCXARecovery entry in the config. Or just leave it be - it's disabled automatically if not required.

A Stateful Session Bean call interrupted by a node failure followed by a transparent failover to a second node. Would I get an error, that the tx couldn't be propagated to the failover node?

I have no idea - you need an EJB container guru or a test case :-)

Jonathan Halliday wrote:

 

> Am I missing something?

 

yup - crash recovery testing. You didn't test it, so you don't know if it will work. Hint: it won't - crash rec wiring is not automatic in that version.

You're right, I didn't do such testing. I did test the regular commit and rollback when one of the resources threw an exception. I.e. simply throwing an exception as the last statement in the session bean's method will correctly rollback the work done for any of the resources that participated in the transaction till thus far.

An actual crash of the server might be harder to test. I could set a break point on the last statement in the session bean's method and then kill -9 the main coordinating JBoss AS. Is that the situation you're referring to?

A bit harder to test would be crashes of the main coordinating JBoss AS that happen between calling prepare on the various participating resources and between calling commit. Any advice on how to test this? I guess I could set a break point in the TM somewhere, but it will probably be a little tricky to locate the correct place.

Thanks for pointing this out to me.

Putting breakpoints in user code won't test recovery as the whole 2PC happens under the commit call to the transaction manager. Even that may not be in user code - it's often done by the EJB tx interceptor. If you have source code for JBossTS then it is the return from BasicAction.prepare that you need to break on to test top down (i.e. driven from the tx manager logs) recovery, but that's only one of several possible crash scenarios. If you're seriously paranoid then you need a good transactions book and a copy of byteman or a dummy XAResource implementation.

Jonathan Halliday wrote:

 

Putting breakpoints in user code won't test recovery as the whole 2PC happens under the commit call to the transaction manager. Even that may not be in user code - it's often done by the EJB tx interceptor.

I ofcourse intended to put the breakpoints in the JBoss AS code for testing failures during the prepare and commit phases

If you're seriously paranoid then you need a good transactions book and a copy of byteman or a dummy XAResource implementation.

In this case I'm not particularly paranoid As long as the basic commit and rollback for all resources after an exception works, I'm happy. This seems to work out of the box, without needing any additional configuration.

For my specific usecase, I can tolerate a little inconsistency in the very unlikely case that the one and only server I use crashes exactly while in the midst of the prepare or commit phase.

Still I'm curious what exactly 'does not work' entails. Does JBoss AS detects that there is an unfinished TX and then refuses to start up the next time, or is the only consequence that I have a possible inconsistent state?

(I am going to test this though, as I'm curious to how this crash recovery works)

testrot wrote:

 

I have no idea - you need an EJB container guru or a test case :-)

If I ever see one I will ask him ;-). Meanwhile I will use a test case or just pray everything works as I think.

http://community.jboss.org/people/jaikiran?