1 2 3 Previous Next 74 Replies Latest reply: May 17, 2006 1:02 AM by mskonda RSS

XARecovery: Messaging integration with JBoss Transactions

mskonda Apprentice

I think this is the way forward:

1. Create MessagingXARecoveryModule class (One named XARecoveryModule is already available wiht the current distribution of JBoss Transactions. But I am not sure whether it can be used/reuse.)

2. Quote this module class in the JTA properties file so that the RecoveryManager can instantiate.

3. Quote the relevant configurational (probably jndi name of the XAConnectionFactory) parameters in the properties file so that the module class can be initialised when instantiated.

4. Write a test case: prepare the transaction and crash the server(which leaves an uncommitted transaction).

5. Ideally when the server returns back, the RecoveryManager, with the help of RecoveryModule should grab the incompleted-prepared transaction from the objectstore and process.

This is my understanding. Throw your thoughts too, please

/K

  • 1. Re: XARecovery: Messaging integration with JBoss Transaction
    Mark Little Master

    If you're just using XAResources and nothing implementation specific, then the default XARecoveryModule in JBossTS should work for you. I'd recommend that you make your XAResources serializable: it'll save you a lot of time and effort in the long run.

  • 2. Re: XARecovery: Messaging integration with JBoss Transaction
    mskonda Apprentice

    Mark, I have created a testbed where an MDB's onMessage does the following work in a tx after connecting to a DB and JMS to update and publish data respectively:

    1. Send a message
    2. Update a table
    3. Just before returning from the onMessage() (after doing 1 & 2 operations), kill the server manually

    The expected behaviour:

    When the server comes back, the table must be committed/rollback and so is JMS. I expect this via RecoveryManager (as the server crashed before a Tx is committed).

    This is what I did:

    In my jbossjta-properties.xml, I have added the following properties to recoverymanager part:

    <property name="com.arjuna.ats.arjuna.recovery.recoveryExtension3" value="com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule"/>
    <property name="com.arjuna.ats.jta.recovery.XAResourceRecoveryMessaging" value="com.mizuho.london.cmi2.recovery.MessagingXAResourceRecovery;hello=world"/>
    


    I expect the XARecoveryModule to start recovery (using MessagingXAResourceRecovery) when the server backs up.

    Unfortunately when the server backs up, the recovery is not kicked in. I am thinking something to do with configurational settings. BTW, I'm passing
    <property name="com.arjuna.ats.jta.xaRecoveryNode" value="*"/>

    so I can recover all the tx's for the time being.
    Any obvious mistakes?

    I would appreciate any help.

    Thanks

  • 3. Re: XARecovery: Messaging integration with JBoss Transaction
    Tim Fox Master

     

    "mskonda" wrote:
    I think this is the way forward:

    1. Create MessagingXARecoveryModule class (One named XARecoveryModule is already available wiht the current distribution of JBoss Transactions. But I am not sure whether it can be used/reuse.)

    2. Quote this module class in the JTA properties file so that the RecoveryManager can instantiate.

    3. Quote the relevant configurational (probably jndi name of the XAConnectionFactory) parameters in the properties file so that the module class can be initialised when instantiated.

    4. Write a test case: prepare the transaction and crash the server(which leaves an uncommitted transaction).



    In order to make sure the transaction is in the prepared state, you need to be careful the transaction manager hasn't joined transactions and is actually doing a 1PC optimsation since the resource managers are the same.

    To see how I force 2PC, see org.jboss.test.messaging.jmsXATest - you probably want to do something similar.



    5. Ideally when the server returns back, the RecoveryManager, with the help of RecoveryModule should grab the incompleted-prepared transaction from the objectstore and process.


    We are not currently using the JBoss Transactions object store. On recovery you need to "resurrect" the transaction instance from the database (since that is currently acting as our transaction log) and add it to the transaction repository. Whether this is done on startup or on demand is another question..



    This is my understanding. Throw your thoughts too, please

    /K


  • 4. Re: XARecovery: Messaging integration with JBoss Transaction
    Tim Fox Master

    Any tests for this should not rely on MDBs, since they are functionality of JBoss AS, not JBoss Mesaging.

  • 5. Re: XARecovery: Messaging integration with JBoss Transaction
    Mark Little Master

     

    "mskonda" wrote:
    Mark, I have created a testbed where an MDB's onMessage does the following work in a tx after connecting to a DB and JMS to update and publish data respectively:

    1. Send a message
    2. Update a table
    3. Just before returning from the onMessage() (after doing 1 & 2 operations), kill the server manually

    The expected behaviour:

    When the server comes back, the table must be committed/rollback and so is JMS. I expect this via RecoveryManager (as the server crashed before a Tx is committed).

    This is what I did:

    In my jbossjta-properties.xml, I have added the following properties to recoverymanager part:
    <property name="com.arjuna.ats.arjuna.recovery.recoveryExtension3" value="com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule"/>
    <property name="com.arjuna.ats.jta.recovery.XAResourceRecoveryMessaging" value="com.mizuho.london.cmi2.recovery.MessagingXAResourceRecovery;hello=world"/>
    


    I expect the XARecoveryModule to start recovery (using MessagingXAResourceRecovery) when the server backs up.

    Unfortunately when the server backs up, the recovery is not kicked in.


    First of all I'm assuming you're running in JBossAS 4.0.3SP1 and JBossTS has been configured in using just the local JTA implementation?

    When you say that recovery isn't running, how are confirming this? Usually you'd see things like:

    14:03:08,156 INFO [TransactionManagerService] Recovery manager started

    14:03:08,156 INFO [TransactionManagerService] Binding TransactionManager JNDI Reference

    14:03:08,156 INFO [arjLogger] Periodic recovery - first pass <Wed, 10 May 2006 14:03:08>

    14:03:08,156 INFO [arjLogger] StatusModule: first pass

    14:03:08,156 INFO [txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_3] - TORecoveryModule - first pass

    14:03:08,156 INFO [loggerI18N] [com.arjuna.ats.internal.jts.recovery.transactions.TopLevelTransactionRecoveryModule_3] [com.arjuna.ats.internal.jts.recovery.transactions.TopLevelTransactionRecoveryModule_3] - TopLevelTransactionRecoveryModule First Pass

    14:03:08,156 INFO [logger] TransactionRecoveryModule.periodicWorkFirstPass()

    14:03:08,156 INFO [loggerI18N] [com.arjuna.ats.internal.jts.recovery.transactions.ServerTransactionRecoveryModule_3] [com.arjuna.ats.internal.jts.recovery.transactions.ServerTransactionRecoveryModule_3] - ServerTransactionRecoveryModule - First Pass

    14:03:08,156 INFO [logger] TransactionRecoveryModule.periodicWorkFirstPass()

    14:03:08,156 INFO [logger] Local XARecoveryModule - first pass

    14:03:08,171 INFO [logger] JTS XARecoveryModule - first pass

    in your JBossAS log file. Is that the case?

    I am thinking something to do with configurational settings. BTW, I'm passing
    <property name="com.arjuna.ats.jta.xaRecoveryNode" value="*"/>

    so I can recover all the tx's for the time being.
    Any obvious mistakes?

    I would appreciate any help.

    Thanks


    Well let's just check that the recovery manager is running first.

  • 6. Re: XARecovery: Messaging integration with JBoss Transaction
    Mark Little Master

     

    "timfox" wrote:
    "mskonda" wrote:
    I think this is the way forward:

    1. Create MessagingXARecoveryModule class (One named XARecoveryModule is already available wiht the current distribution of JBoss Transactions. But I am not sure whether it can be used/reuse.)

    2. Quote this module class in the JTA properties file so that the RecoveryManager can instantiate.

    3. Quote the relevant configurational (probably jndi name of the XAConnectionFactory) parameters in the properties file so that the module class can be initialised when instantiated.

    4. Write a test case: prepare the transaction and crash the server(which leaves an uncommitted transaction).



    In order to make sure the transaction is in the prepared state, you need to be careful the transaction manager hasn't joined transactions and is actually doing a 1PC optimsation since the resource managers are the same.


    Obviously having a couple of resources registered in the transaction will prevent this optimisation. However, if you're running with JBossTS, then you can disable the one-phase commit optimization at deployment time (only recommended for testing purposes), using the com.arjuna.ats.arjuna.coordinator.commitOnePhase property (set it to NO).


    To see how I force 2PC, see org.jboss.test.messaging.jmsXATest - you probably want to do something similar.



    5. Ideally when the server returns back, the RecoveryManager, with the help of RecoveryModule should grab the incompleted-prepared transaction from the objectstore and process.


    We are not currently using the JBoss Transactions object store. On recovery you need to "resurrect" the transaction instance from the database (since that is currently acting as our transaction log) and add it to the transaction repository. Whether this is done on startup or on demand is another question..



    This is my understanding. Throw your thoughts too, please

    /K


    Yes, not using JBossTS would be a problem for the recovery manager. When are you guys going to move over ;-)?

  • 7. Re: XARecovery: Messaging integration with JBoss Transaction
    mskonda Apprentice

     


    Well let's just check that the recovery manager is running first.


    I can confirm that RecoveryManager is running.

  • 8. Re: XARecovery: Messaging integration with JBoss Transaction
    Mark Little Master

    In which case, how do you know it isn't calling your RecoveryModule plugin? I assume you're seeing the output from the other modules?

  • 9. Re: XARecovery: Messaging integration with JBoss Transaction
    mskonda Apprentice

     

    <property name="com.arjuna.ats.jta.recovery.XAResourceRecoveryMessaging"
    value="om.mizuho.london.cmi2.recovery.MessagingXAResourceRecovery"/>
    


    1. There's no reference to the class anywhere in the log file (log level set to DEBUG).
    2. No complains inspite of wrong name (See deliberate spelling mistake of com package- should be com.mizuho..)


  • 10. Re: XARecovery: Messaging integration with JBoss Transaction
    Mark Little Master

    So next thing: how do you know anything needs recovering ;-)? If there are no entries in the log then the recovery manager won't do anything and hence it won't call your class.

  • 11. Re: XARecovery: Messaging integration with JBoss Transaction
    mskonda Apprentice

    Yup, that's the right conclusion Mark.

    The next step is either

    1. Make messaging use JBossTS or
    2. retrive the transactions from the JbossMessaging persitent store (I use Sybase) and *transfer* them to JBossTS ObjectStore

    I think the second option is clumsy!

  • 12. Re: XARecovery: Messaging integration with JBoss Transaction
    Mark Little Master

    Definitely not option 2 ;-)

    If your JMS session is within the scope of a JBossTS transaction, then the XAResource that messaging registered with the transaction should be saved to the transaction log. If that's not the case, then there may be something wrong with the XAResource implementation (e.g., it's not two-phase, it only ever returns read-only during prepare, ...)

  • 13. Re: XARecovery: Messaging integration with JBoss Transaction
    mskonda Apprentice

    The transaction log messaging uses is the database.

  • 14. Re: XARecovery: Messaging integration with JBoss Transaction
    Mark Little Master

    That's the place the JMS XAResource participant logs information, surely?

1 2 3 Previous Next