jbossts-issues February 2020

jbossts-issues@lists.jboss.org

1 participants
94 discussions

[JBoss JIRA] (JBTM-3249) XA_RB* exception at prepare incorrectly still calls rollback.

by Jonathan Halliday (Jira)

Jonathan Halliday created JBTM-3249: --------------------------------------- Summary: XA_RB* exception at prepare incorrectly still calls rollback. Key: JBTM-3249 URL: https://issues.redhat.com/browse/JBTM-3249 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.10.3.Final Reporter: Jonathan Halliday XAResourceRecord.topLevelPrepare maps XA_RB* codes as PREPARE_NOTOK, which causes ArjunaCore to re-queue the record on the pending list and subsequently call topLevelAbort. This is incorrect from an XA spec perspective, as XA_RB at prepare indicates the RM has terminated and forgotten the tx, so a rollback thereafter may causes unexpected problems. Whereas the elegant fix is probably a new TwoPhaseOutcome to distinguish 'NOTOK, don't call me again' from 'NOTOK, roll me back', that's a bit of a pain. The alternative is to leverage the mechanism we already have for employing this optimization in cases where we can, and extend it to cases where we should. {code:java} switch (e1.errorCode) { case XAException.XA_RBROLLBACK: case XAException.XA_RBEND: case XAException.XA_RBCOMMFAIL: case XAException.XA_RBDEADLOCK: case XAException.XA_RBINTEGRITY: case XAException.XA_RBOTHER: case XAException.XA_RBPROTO: case XAException.XA_RBTIMEOUT: // we may want to pull XAER_NOTA up here too? if (_theTransaction != null) { _theTransaction.setXAResourceState(_theXAResource, TxInfo.OPTIMIZED_ROLLBACK); // in a perfect word we'd call removeConnection here, but we probably need to do in in topLevelAbort instead, unless we change its implementation } // now fall through... case XAException.XAER_RMERR: case XAException.XAER_RMFAIL: case XAException.XAER_INVAL: case XAException.XAER_PROTO: case XAException.XAER_NOTA: // resource may have arbitrarily rolled back (shouldn't, but ...) return TwoPhaseOutcome.PREPARE_NOTOK; // will not call rollback [*cough*bullshit*cough*] default: return TwoPhaseOutcome.HEURISTIC_HAZARD; // we're not really sure (shouldn't get here though). } {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3248) BLACKTIE: CSTest.test_215 failed

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3248?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3248: ---------------------------------------- BLACKTIE: CSTest.test_215:65->CSControl.runTest:154 > BLACKTIE: CSTest.test_215 failed > -------------------------------- > > Key: JBTM-3248 > URL: https://issues.redhat.com/browse/JBTM-3248 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Thomas Jenkinson > Assignee: Zheng Feng > Priority: Major > > We have seen failures in CI for this test -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3248) BLACKTIE: CSTest.test_215 failed

by Thomas Jenkinson (Jira)

Thomas Jenkinson created JBTM-3248: -------------------------------------- Summary: BLACKTIE: CSTest.test_215 failed Key: JBTM-3248 URL: https://issues.redhat.com/browse/JBTM-3248 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Thomas Jenkinson Assignee: Zheng Feng We have seen failures in CI for this test -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3247) Failed LRA records are reported but they not kept

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3247: -------------------------------------- Summary: Failed LRA records are reported but they not kept Key: JBTM-3247 URL: https://issues.redhat.com/browse/JBTM-3247 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.10.3.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next When an LRA is closed/cancelled and some participants will never be able to complete/compensate then they are placed on the [BasicAction] failedList. The MP-LRA spec only requires that such failures are logged. The narayana implementation does indeed log the failure (using a log WARNING statement) but then removes the transaction record from the object store. It would be preferable to leave failed LRA's in the store and allow them to be queried and deleted using the REST coordinator (like we do for recovering LRA's). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues February 2020