July 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2907. ------------------------------- Resolution: Done > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.5.25.Final, 5.6.2.Final > > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/clas...). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2908) JCA committed inflow transaction is not moved to assumed completed category for JTS

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2908?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2908: -------------------------------- Fix Version/s: 5.5.25.Final (was: 5.2.25.Final) > JCA committed inflow transaction is not moved to assumed completed category for JTS > ----------------------------------------------------------------------------------- > > Key: JBTM-2908 > URL: https://issues.jboss.org/browse/JBTM-2908 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.6.2.Final, 5.5.25.Final > > > We have test which checks whether EIS is capable to finish transaction after JVM crash. > The scenario is following: > - 2 test XA resources are enlisted > - EIS RAR XATerminator calls prepare and commit > - JVM crash occurs at the start of the first XAResource.commit call > - app server is restarted > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are not rolled-back > - EIS XATerminator.commit is called > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are committed > but the committed tx is not removed from log: > {code} > jvmCrashAfterPrepareJTS(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 125.532 sec <<< FAILURE! > java.lang.AssertionError: After commiting txn there should be no one in the txn log expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepareJTS(JcaInflowTransactionTestCase.java:763) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2916?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2916: -------------------------------- Fix Version/s: 5.2.25.Final > Disable dynamic1PC for subordinate transactions > ----------------------------------------------- > > Key: JBTM-2916 > URL: https://issues.jboss.org/browse/JBTM-2916 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.25.Final, 5.5.28.Final, 5.next > > > If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. > This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2908) JCA committed inflow transaction is not moved to assumed completed category for JTS

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2908?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-2908: --------------------------------- > JCA committed inflow transaction is not moved to assumed completed category for JTS > ----------------------------------------------------------------------------------- > > Key: JBTM-2908 > URL: https://issues.jboss.org/browse/JBTM-2908 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.2.25.Final, 5.6.2.Final > > > We have test which checks whether EIS is capable to finish transaction after JVM crash. > The scenario is following: > - 2 test XA resources are enlisted > - EIS RAR XATerminator calls prepare and commit > - JVM crash occurs at the start of the first XAResource.commit call > - app server is restarted > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are not rolled-back > - EIS XATerminator.commit is called > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are committed > but the committed tx is not removed from log: > {code} > jvmCrashAfterPrepareJTS(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 125.532 sec <<< FAILURE! > java.lang.AssertionError: After commiting txn there should be no one in the txn log expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepareJTS(JcaInflowTransactionTestCase.java:763) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-2907: --------------------------------- > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.2.25.Final, 5.6.2.Final > > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/clas...). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2916?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2916: -------------------------------- Fix Version/s: 5.5.28.Final > Disable dynamic1PC for subordinate transactions > ----------------------------------------------- > > Key: JBTM-2916 > URL: https://issues.jboss.org/browse/JBTM-2916 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.5.28.Final, 5.next > > > If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. > This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2917) Disable dynamic1PC for subordinate transactions

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-2917: ----------------------------------- Summary: Disable dynamic1PC for subordinate transactions Key: JBTM-2917 URL: https://issues.jboss.org/browse/JBTM-2917 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Tom Jenkinson Assignee: Tom Jenkinson Priority: Blocker Fix For: 5.next If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-2916: ----------------------------------- Summary: Disable dynamic1PC for subordinate transactions Key: JBTM-2916 URL: https://issues.jboss.org/browse/JBTM-2916 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2916?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2916: -------------------------------- Priority: Blocker (was: Major) > Disable dynamic1PC for subordinate transactions > ----------------------------------------------- > > Key: JBTM-2916 > URL: https://issues.jboss.org/browse/JBTM-2916 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.next > > > If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. > This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2915) Let NarayanaJtaServletContextListener be deployed without need for web.xml change

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2915?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2915: -------------------------------- Fix Version/s: 5.next (was: 5.6.3.Final) > Let NarayanaJtaServletContextListener be deployed without need for web.xml change > --------------------------------------------------------------------------------- > > Key: JBTM-2915 > URL: https://issues.jboss.org/browse/JBTM-2915 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Currently you need a web.xml with the listener in it but if you annotate the class with javax.servlet.annotation.WebListener it will deploy automatically. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues July 2017