8 Replies Latest reply: Feb 22, 2014 11:04 AM by Bond Chan RSS

How to fall back to the legacy JBossTM fast in-memory transa

Tina Muehle Newbie

Hi,

we migrated from JBOSS 4.0.4 to 4.2.2. The 4.2.2 version uses by default the Arjuna TS. How can we fall back to the legacy JBossTM fast in-memory transaction manager which was the default in JBOSS 4.0.4?

Tina

  • 1. Re: How to fall back to the legacy JBossTM fast in-memory tr
    Andrew Dinn Master

     


    How can we fall back to the legacy JBossTM fast in-memory transaction manager which was the default in JBOSS 4.0.4?


    The only way to achieve this is to downgrade to JBoss 4.0.4.

    Anyway, why do you want to go back to a Transaction Manager which does not make your data secure? If you don't want crash recovery then you might as well not bother with transactions in the first place.

    By the way, when we ran performance tests on JBoss 4.2.2 the new TM based on Arjuna was no slower than the old 'fast, in-memory' TM which was inlcuded in 4.0.4. It had to be otherwise we would not have been able to include it in the release. So, performance problems should not be a reason to put your data at risk.


  • 2. Re: How to fall back to the legacy JBossTM fast in-memory tr
    Tina Muehle Newbie

     


    The only way to achieve this is to downgrade to JBoss 4.0.4.


    The release notes for JBOSS 4.2.x state:

    JBoss Transactions v4.2 is the default transaction manager for JBossAS 4.2...
    ... it is always possible to fall back to the legacy JBossTM fast in-memory transaction manager implementation, if necessary.


    This sounds like a switch to the old transaction manager within JBOSS 4.2.2 wouldn't be a problem. Anyway I agree that we should stay with ArjunaTS. However, we experience a problem after migrating to JBOSS 4.2.2 which does not occur on JBOSS 4.0.4 using the old transaction manager.

    Maybe you can generally enlight why the following message occurs:

    [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_36] - BasicAction.End() - prepare phase of action-id -53e3ca3f:c061:47de2e24:b9 failed.
    09:39:47,605 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_38] - Action Aborting
    09:39:47,605 WARN [logger] XAOnePhaseResource.rollback(< 131075, 28, 26, 1--53e3ca3f:c061:47de2e24:b9-53e3ca3f:c061:47de2e24:bd >) wrong xid in rollback: expected: null, got: < 131075, 28, 26, 1--53e3ca3f:c061:47de2e24:b9-53e3ca3f:c061:47de2e24:bd >
    09:39:47,611 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_54] - Top-level abort of action -53e3ca3f:c061:47de2e24:b9 received TwoPhaseOutcome.FINISH_ERROR from <ClassName:RecordType.LASTRESOURCE>
    


    We still have the app running on JBOSS 4.0.4 too where the same process is done without any problem. What does wrong xid in rollback mean? What is the possible reason for this exception?

    Tina

  • 3. Re: How to fall back to the legacy JBossTM fast in-memory tr
    Andrew Dinn Master

     


    Maybe you can generally enlight why the following message occurs:


    You need to look at the full sequence of messages. I've explained what I can below.

    Also, note that the fact that things worked in the old TM/JBoss does not mean your code is correct. The new TM identifies error cases which were not identified by the old one. These cases may not have caused errors in the past but they could do.


    [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_36] - BasicAction.End() - prepare phase of action-id -53e3ca3f:c061:47de2e24:b9 failed.
    09:39:47,605 WARN [arjLoggerI18N]


    This first message means that a resource enlisted in your transaction returned a fail when it was asked to prepare during 2 phase commit. Why this happened depends upon the type of resource in question and what you program does with it.


    [com.arjuna.ats.arjuna.coordinator.BasicAction_38] - Action Aborting


    This second message indicates that the transaction has is being aborted because of the prepare failure.


    09:39:47,605 WARN [logger] XAOnePhaseResource.rollback(< 131075, 28, 26, 1--53e3ca3f:c061:47de2e24:b9-53e3ca3f:c061:47de2e24:bd >)
    wrong xid in rollback : expected: null, got: < 131075, 28, 26, 1--53e3ca3f:c061:47de2e24:b9-53e3ca3f:c061:47de2e24:bd >


    This message comes from an XAOnePhaseResource wrapper instance whose rollback() method has been called. This wrapper is used to wrap an underlying resource when you enlist it as the last resource in a transaction because it does not support 2 phase commit. The error means that when the wrapper called the underlying resource's rollback method an exception was thrown.

    The 'expected null got ...' text in the message is derived from the exception. So, the underlying resource expected a null id to be supplied and instead was passed the id whose print representation is included in the message. Again, why this is happening depends upon the underlying XAResource and how it has been set up. It may well be that this is the resource which failed to prepare in which case the failure to handle a rollback is probably not very significant (althoguh the fact that it cannto cope with a prepare failure is a problem). What you need to do is work out why your resource failed to prepare.


    09:39:47,611 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_54] - Top-level abort of action -53e3ca3f:c061:47de2e24:b9 received TwoPhaseOutcome.FINISH_ERROR from <ClassName:RecordType.LASTRESOURCE>


    This message is printed by XAOnePhaseResource to indicate that it received an exception from the underlying resource and is returning an error to indicate that the 2PC rollback has failed.


  • 4. Re: How to fall back to the legacy JBossTM fast in-memory tr
    Tina Muehle Newbie

    First, thanks for your great explanation.

    What came to me at first glance is that you talked about

    fail when it was asked to prepare during 2 phase commit
    and
    enlist it as the last resource in a transaction because it does not support 2 phase commit.


    Maybe there is just a misconfiguration in our settings!? We use Stateless Session Beans (TransactionAttribute is set to 'REQUIRED' for all EJB methods). We do not need 2PC because we only have local transactions. Do we have to explicitly declare this?

    Tina


  • 5. Re: How to fall back to the legacy JBossTM fast in-memory tr
    Andrew Dinn Master

     


    Maybe there is just a misconfiguration in our settings!? We use Stateless Session Beans (TransactionAttribute is set to 'REQUIRED' for all EJB methods). We do not need 2PC because we only have local transactions. Do we have to explicitly declare this?


    I talked about 2PC because your log trace showed that a 2PC was taking place, This means that you must have used more than one resource in your transaction. If you are using multiple resources then you need to use 2PC to ensure that you don't get a mixed outcome from your commit (one resource commits then a second one fails).

    The last resource issue is to do with integrating a single resource which only supports commit into a transaction with other resources which support 2PC. If there is _one_ resource which supports commit but not prepare then you can still run a safe 2PC. The TM will prepare all the 2PC resources then attempt to commit the resource which does not support a prepare. If this succeeds then it commits the other resources. if it fails the TM rolls back the other resources. This does not work if you have two resources which can commit but not prepare.

    If you are still not clear about why 2PC is necessary I think maybe you ought to go back to basics and read a bit more about how transactions work. I recommend Mark Little's book -- not (just :-) because he's my boss but because it is an extremely readable explanation of how transactions work and why you need a fully functional TM like the current JBossTS product.

  • 6. Re: How to fall back to the legacy JBossTM fast in-memory tr
    Vicky Kak Master

     

    "adinn" wrote:

    The only way to achieve this is to downgrade to JBoss 4.0.4.


    This does not seem to be correct .
    You can fall back by configuring the OlderTM in $JBOSS_HOME/server/default/conf/jboss-service.xml .

    Check this
     <!--
     | The fast in-memory transaction manager.
     | Deprecated in JBossAS v4.2. Use JBossTS JTA instead.
     - ->
     <mbean code="org.jboss.tm.TransactionManagerService"
     name="jboss:service=TransactionManager"
     xmbean-dd="resource:xmdesc/TransactionManagerService-xmbean.xml">
     <attribute name="TransactionTimeout">300</attribute>
     <!- - set to false to disable transaction demarcation over IIOP - ->
     <attribute name="GlobalIdsEnabled">true</attribute>
     <depends optional-attribute-name="XidFactory">jboss:service=XidFactory</depends>
    
     <!- - Transaction Integrity Checking - ->
     <!- - Force a rollback if another thread is associated with the transaction at commit - ->
     <!- - <depends optional-attribute-name="TransactionIntegrityFactory"
     proxy-type="org.jboss.tm.integrity.TransactionIntegrityFactory">
     <mbean code="org.jboss.tm.integrity.FailIncompleteTransaction"
     name="jboss:service=TransactionManager,plugin=TransactionIntegrity"/>
     </depends> - ->
     </mbean>
     -->
    


    Uncomment this section and comment the JBossTS , I have not tried this .

    You must stay with JbossTS as this is the *REAL* TM , it contains the TransactionRecovery which were not the part of the olderTM .
    TransactionRecovery is heart of any TM implementaion ;)



  • 7. Re: How to fall back to the legacy JBossTM fast in-memory tr
    Mark Little Master

    Try to fix your problem while still using the "new" (been around for 20+ years) TM.

  • 8. Re: How to fall back to the legacy JBossTM fast in-memory transa
    Bond Chan Novice

    Hi Andrew,

     

    I have exactly the same log, how can I found out which resource can't be get parepred, see my case.trsanction aborted/rollbacked with un-understand exception