September 2014 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2257) Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2257?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-2257: ---------------------------- Component/s: Application Server Integration > Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT > ----------------------------------------------------- > > Key: JBTM-2257 > URL: https://issues.jboss.org/browse/JBTM-2257 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.4 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2257) Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2257?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-2257: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/730 > Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT > ----------------------------------------------------- > > Key: JBTM-2257 > URL: https://issues.jboss.org/browse/JBTM-2257 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.4 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2257) Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT

by Amos Feng (JIRA)

Amos Feng created JBTM-2257: ------------------------------- Summary: Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT Key: JBTM-2257 URL: https://issues.jboss.org/browse/JBTM-2257 Project: JBoss Transaction Manager Issue Type: Task Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.0.4 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-2256: ----------------------------------- If you can't reproduce it then you're just going by looking through the code? Would be better if we had something that reproduced. > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2256: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/728, https://github.com/jbosstm/narayana/pull/729 > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2256: ---------------------------------- Description: In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. Swapping these two actions should solve the problem. was:In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time. Personally I couldn't reproduce the problem. Swapping these two actions should solve the problem. > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBTM-2256: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1104584 > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner

by Gytis Trikleris (JIRA)

Gytis Trikleris created JBTM-2256: ------------------------------------- Summary: Race condition between recovery manager initialization and expiry scanner Key: JBTM-2256 URL: https://issues.jboss.org/browse/JBTM-2256 Project: JBoss Transaction Manager Issue Type: Bug Components: Transaction Core Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 4.17.23, 5.0.4 In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time. Personally I couldn't reproduce the problem. Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-2255: ----------------------------------- Unfortunately this change is not guaranteed to work in all situations. You are assuming that GenericRecoveryCoordinator is a local instance to the transaction manager/coordinator but it isn't. This comes from the OTS specification and if you run through the various ways in which the status variable can be set (at the start of the method) you'll see that a) it can be remote from the coordinator and b) the status may even be obtained remotely. So there's a very good chance that BasicAction information isn't available to the GenericRecoveryCoordinator because it simply isn't in the same process. > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2255: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 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 September 2014