[jbossts-issues] [JBoss JIRA] (JBTM-1718) Resolve the ParticipantCompletion race condition
Paul Robinson (JIRA)
jira-events at lists.jboss.org
Wed Aug 7 05:41:26 EDT 2013
[ https://issues.jboss.org/browse/JBTM-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795534#comment-12795534 ]
Paul Robinson commented on JBTM-1718:
I think the simplest way to solve this is to add a synchronous version of BAParticipantManager#completed, called BAParticipantManager#completedWithWait (or something better if anyone can think of anything?). The developer can then chose which to use.
Generally speaking, we then need to add another method to BusinessAgreementWithParticipantCompletionCoordinatorPortTypeImpl which is similar to the completed oporation, but has no async capabailities. This is roughly what i was thinking:
@WebMethod(operationName = "completedOperationWithWaitOperation", action = "http://docs.oasis-open.org/ws-tx/wsba/2006/06/CompletedWitWait")
public void completedOperationWithWait(
@WebParam(name = "Completed", targetNamespace = "http://docs.oasis-open.org/ws-tx/wsba/2006/06", partName = "parameters")
MessageContext ctx = webServiceCtx.getMessageContext();
final NotificationType completed = parameters;
final MAP inboundMap = AddressingHelper.inboundMap(ctx);
final ArjunaContext arjunaContext = ArjunaContext.getCurrentContext(ctx);
ParticipantCompletionCoordinatorProcessor.getProcessor().completed(completed, inboundMap, arjunaContext) ;
As well as updating the above class, we would also need to make sure any other Web Service related artefacts are also updated (wsdl for example).
As a starting point I would attach a debugger, and trace through the code to see what happens when 'completed' is invoked. This should help you to understand how to create the synchronous version.
> 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
More information about the jbossts-issues