Back to bug 1032641

Who When What Removed Added
Ondrej Chaloupka 2013-11-20 14:19:36 UTC Target Release --- EAP 6.3.0
Martin Simka 2013-11-20 16:04:00 UTC Component Transaction Manager JCA
Assignee tom.jenkinson jpederse
QA Contact ochaloup vrastsel
CC msimka
QA Contact vrastsel msimka
Jesper Pedersen 2013-11-21 03:30:03 UTC Assignee jpederse smaestri
Ondrej Chaloupka 2013-11-21 08:23:25 UTC CC ochaloup
Radim Hatlapatka 2013-11-22 14:37:58 UTC CC rhatlapa
Jesper Pedersen 2013-11-25 13:17:31 UTC CC jpederse
Stefano Maestri 2014-09-10 14:23:54 UTC Status NEW ASSIGNED
Target Release EAP 6.3.0 EAP 6.4.0
John Mazzitelli 2014-09-12 13:30:53 UTC Blocks 1127272
Stefano Maestri 2014-10-10 15:59:00 UTC Assignee smaestri tom.jenkinson
Ondrej Chaloupka 2014-10-13 07:28:36 UTC CC hhovsepy
Jesper Pedersen 2014-10-24 16:25:26 UTC Assignee tom.jenkinson mmusgrov
Component JCA Transaction Manager
QA Contact msimka ochaloup
Jesper Pedersen 2014-11-03 14:15:09 UTC Link ID JBoss Issue Tracker JBTM-2282
Ondrej Chaloupka 2014-11-03 14:52:20 UTC Status ASSIGNED VERIFIED
Lucas Costi 2015-01-27 01:39:27 UTC CC lcosti
Michael 2015-03-02 10:56:10 UTC Doc Text Cause: Transaction recovery operates by asking resources for their view of in-doubt transaction branches. We use a "RecoveryHelper" which JCA registers with us to achieve this. When the resource is removed from the system the helper is de-registered. There was a race condition in the code whereby if the removal happened during a "recovery scan" then the helper was not removed.

Consequence: This resulted in the possibility that transaction recovery would continue using resources even though they had been removed from the server (which can manifest as IllegalState Exceptions). This underlying cause is the same issue as BZ 1143947.

Fix: If the current scan is using the resource wait for it to finish and then remove the helper.
Scott Mumford 2015-03-03 00:44:19 UTC CC smumford
Doc Text Cause: Transaction recovery operates by asking resources for their view of in-doubt transaction branches. We use a "RecoveryHelper" which JCA registers with us to achieve this. When the resource is removed from the system the helper is de-registered. There was a race condition in the code whereby if the removal happened during a "recovery scan" then the helper was not removed.

Consequence: This resulted in the possibility that transaction recovery would continue using resources even though they had been removed from the server (which can manifest as IllegalState Exceptions). This underlying cause is the same issue as BZ 1143947.

Fix: If the current scan is using the resource wait for it to finish and then remove the helper.
Previous versions of JBoss EAP 6 could encounter an `IllegalStateException` during some transaction recovery operations.

The transaction recovery system operates by querying resources for their view of 'in-doubt' transaction branches. It uses a "RecoveryHelper" which JCA registers to achieve this.

When a resource is removed from the system, the RecoveryHelper is de-registered. In previous versions of the product there was a race condition in the code whereby if the removal happened during a "recovery scan" then the helper was not removed.

This resulted in the possibility that transaction recovery would continue using resources even though they had been removed from the server (which could produce the `IllegalStateExceptions`).

In this release, if the current recovery scan is using the resource, it waits for it to finish and then remove the helper.
Scott Mumford 2015-03-04 00:45:30 UTC CC mmusgrov
Flags needinfo?(mmusgrov)
Lucas Costi 2015-03-04 03:08:13 UTC CC lcosti
Michael 2015-03-04 10:07:40 UTC Flags needinfo?(mmusgrov)
Russell Dickenson 2017-10-10 00:17:34 UTC Docs Contact rdickens
PnT Account Manager 2018-03-05 15:29:29 UTC CC rhatlapa
PnT Account Manager 2018-03-06 20:37:01 UTC CC smumford
Jan Kurik 2019-08-19 12:42:44 UTC Status VERIFIED CLOSED
Resolution --- CURRENTRELEASE
Last Closed 2019-08-19 12:42:44 UTC
Jan Kurik 2019-08-19 12:43:19 UTC Last Closed 2019-08-19 12:42:44 UTC

Back to bug 1032641