[jbossts-issues] [JBoss JIRA] (JBTM-1155) Remember where we are in the commit list for recovery

Tom Jenkinson (JIRA) jira-events at lists.jboss.org
Fri May 4 10:52:18 EDT 2012


    [ https://issues.jboss.org/browse/JBTM-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12690454#comment-12690454 ] 

Tom Jenkinson commented on JBTM-1155:
-------------------------------------

Hi Mark,

I just added a test for this: https://github.com/jbosstm/narayana/commit/61ce31d5f3e3b557c1856869afb73d06b1c46013

The question is, how do I know if its successful? There is something in the object store:
[tom at localhost narayana]$ tree ArjunaJTA/jta/ObjectStore/
ArjunaJTA/jta/ObjectStore/
`-- ShadowNoFileLockStore
    `-- defaultStore
        |-- Recovery
        |   `-- TransactionStatusManager
        `-- StateManager
            `-- BasicAction
                `-- TwoPhaseCoordinator
                    `-- AtomicAction
                        `-- 0_ffff7f000001_a46c_4fa3e84e_11

The test loads this but the status is not AtomicAction.H_ROLLBACK, it is AtomicAction.CREATED (probably fair enough as all I do in the test is load the AtomicAction. What I am trying do work out is how to detect the state of that transaction though, any tips?

Tom
                
> Remember where we are in the commit list for recovery
> -----------------------------------------------------
>
>                 Key: JBTM-1155
>                 URL: https://issues.jboss.org/browse/JBTM-1155
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Recovery, Transaction Core
>    Affects Versions: 4.16.4
>            Reporter: Mark Little
>            Assignee: Mark Little
>             Fix For: 5.0.0.Final
>
>
> We keep track of where the coordinator is in the list of resources to commit during doCommit, so that we can avoid heuristics as much as possible. Basically we need to remember if we have gotten past the first participant. However, we do not remember this value (boolean) as part of the transaction state. This means that upon recovery there is a chance that a participant that failed to commit the first time round and then causes a heuristic rollback subsequently, will cause the transaction silently mask the heuristic and roll back all of the other participants, delete the log and report a normal transaction abort state. In fact it should ensure the heuristic is raised.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the jbossts-issues mailing list