JTS transaction log behavior for heuristic rollback on first participant

[ochaloup]

Hi,

I would like check with you if observed behavior is correct from Narayana functionality point of view. I have a transction where first participant throws heuristic rollback during at commit phase. This is simulation of scenario shown in jira https://issues.jboss.org/browse/JBTM-2120. Scenario is following:

1. enlist xa resource #1
2. enlist xa resource #2
3. preparation phase of xa resources #1 and #2
4. commit xa resource #1 - XAException#XA_HEURRB is thrown, that means XAResource rollbacks on its own
5. TM reacts and as first participant rollbacks for stay consistent it will rollback all subsequent resources
6. rollback xa resource #2

For JTA after transaction finishes, transaction log store is cleaned and is left empty (no recovery is run).

For JTS there is left record of participant which ends with heuristics (no recovery is run). It means log store is not empty after transaction finishes.

Is that correct that JTS does leaves that record in the object store? Is expected that recovery manager takes care of it? Or just by design of JTS such records needs to be left?

Thank you for taking a look at this

Ondra

(added a EAP server.log attachments with this scenario)

[mmusgrov]

For JTA we store the participant records with the transaction record so when the transaction has rolled back we delete the transaction and implicitly the resource that had a heuristic outcome.

For JTS we store participants separately from the transaction. When the transaction rolls back we delete the transaction. When we rollback the second resource we delete its log but when we tried to commit the first resource it did a heuristic rollback and in this case we leave the record in the store since the administrator may need to investigate.

[Edit] Actually I think the log should eventually get cleaned up. Bottom up recovery will find the xid corresponding to the log and determine that its one of ours but that there is no associated transaction so will vote rollback (this decision is made by one of the orphan filters) and then call forget on the resource. The forget will perform the removal of the log record.

[ochaloup]

I got it. Mike, thanks a lot for clarification.