[
https://issues.jboss.org/browse/JBTM-1718?page=com.atlassian.jira.plugin....
]
Paul Robinson commented on JBTM-1718:
-------------------------------------
The current use-case for this is with our implementation of the compensation-based
transactions API. Here it is common to have the coordinator, participants and client on
the same VM and this issue occurs frequently causing unexpected rollbacks. Currently, our
quickstarts for using the compensations API need a Byteman rule to stop this issue
occurring! This is going to put many/most people off when they take a look at it.
As it's only needed internally, maybe we could offer this functionality via some
hidden means that does not appear in the public API and thus doesn't break the
standard for WS-BA users?
Resolve the ParticipantCompletion race condition
------------------------------------------------
Key: JBTM-1718
URL:
https://issues.jboss.org/browse/JBTM-1718
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: TXFramework
Reporter: Paul Robinson
Assignee: Gytis Trikleris
Fix For: 5.0.0.M4
This issue is documented here: JBTM-1429
In the documentation for JBTM-1429, we state that this issue is unlikely to happen in a
distributed environment. This is true, however, the Compensations API is designed to work
local-only as well as distributed over WS-BA. Therefore it is much more likely to happen
in a production environment.
Therefore we need to remove this race condition. It can be done in a proprietary mannor
as we are not interoperating with another implementation ion local-only mode. When
distributing the transaction we fall back to the standard protocol that is susceptible to
the race condition. However, as we stated in the docs, this condition is unlikely to
manifest in a distributed environment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira