August 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1718) Resolve the ParticipantCompletion race condition

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-1718?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-1718: ----------------------------------- If this is only for local transactions, then why not add the API but not extend the WSDL? I'm not sure what you mean by "not appear in the public API" because if this is added to make a quickstart work then someone will find it and use it anyway. > 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1718) Resolve the ParticipantCompletion race condition

by Paul Robinson (JIRA)

[ 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1718) Resolve the ParticipantCompletion race condition

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-1718?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-1718: ----------------------------------- Is this really an issue at the moment? Until/unless someone really complains about this, I think we should wait before breaking compliance with the standard. Interoperability and portability are very important and whilst it can be argued that all other implementations would suffer the same problem, I think we don't have enough user input to really know how important this is when compared to other issues. > 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1718) Resolve the ParticipantCompletion race condition

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-1718?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-1718: ----------------------------------- And a really big comment that this is NOT COMPLIANT WITH THE STANDARD would be useful if you do decide to go down this route. > 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1874) Many quickstarts have a dependency on an old WildFly (8.0.0.Alpha2)

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1874?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1874: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Many quickstarts have a dependency on an old WildFly (8.0.0.Alpha2) > ------------------------------------------------------------------- > > Key: JBTM-1874 > URL: https://issues.jboss.org/browse/JBTM-1874 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Demonstrator, Documentation > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M4 > > -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1876) "OutOfMemoryError: PermGen space" from maven-compiler-plugin in quickstarts

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1876?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1876: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/quickstart/pull/85 > "OutOfMemoryError: PermGen space" from maven-compiler-plugin in quickstarts > --------------------------------------------------------------------------- > > Key: JBTM-1876 > URL: https://issues.jboss.org/browse/JBTM-1876 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Demonstrator, Documentation > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M4 > > > Fix by upgrading plugin from 2.3.1 to 3.1 -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1876) "OutOfMemoryError: PermGen space" from maven-compiler-plugin in quickstarts

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1876?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1876: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > "OutOfMemoryError: PermGen space" from maven-compiler-plugin in quickstarts > --------------------------------------------------------------------------- > > Key: JBTM-1876 > URL: https://issues.jboss.org/browse/JBTM-1876 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Demonstrator, Documentation > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M4 > > > Fix by upgrading plugin from 2.3.1 to 3.1 -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1874) Many quickstarts have a dependency on an old WildFly (8.0.0.Alpha2)

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1874?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1874: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/quickstart/pull/85 > Many quickstarts have a dependency on an old WildFly (8.0.0.Alpha2) > ------------------------------------------------------------------- > > Key: JBTM-1874 > URL: https://issues.jboss.org/browse/JBTM-1874 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Demonstrator, Documentation > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M4 > > -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1682) Create a simple non-transactional-resource compensations quickstart

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1682?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1682: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Create a simple non-transactional-resource compensations quickstart > ------------------------------------------------------------------- > > Key: JBTM-1682 > URL: https://issues.jboss.org/browse/JBTM-1682 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Demonstrator, TXFramework, XTS > Reporter: Paul Robinson > Assignee: Paul Robinson > Priority: Critical > Fix For: 5.0.0.M4 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > It should cover the first example covered in my JUDConn presentation and the associated blog post: http://jbossts.blogspot.co.uk/2013/05/compensating-transactions-when-acid... -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1718) Resolve the ParticipantCompletion race condition

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1718?page=com.atlassian.jira.plugin.... ] Paul Robinson edited comment on JBTM-1718 at 8/7/13 5:41 AM: ------------------------------------------------------------- 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 choose 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: {code} @WebMethod(operationName = "completedOperationWithWaitOperation", action = "http://docs.oasis-open.org/ws-tx/wsba/2006/06/CompletedWitWait") @Action(input="http://docs.oasis-open.org/ws-tx/wsba/2006/06/CompletedWithWait") public void completedOperationWithWait( @WebParam(name = "Completed", targetNamespace = "http://docs.oasis-open.org/ws-tx/wsba/2006/06", partName = "parameters") NotificationType 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) ; } {code} As well as updating the above class, you 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. was (Author: paul.robinson): 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 choose 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: {code} @WebMethod(operationName = "completedOperationWithWaitOperation", action = "http://docs.oasis-open.org/ws-tx/wsba/2006/06/CompletedWitWait") @Action(input="http://docs.oasis-open.org/ws-tx/wsba/2006/06/CompletedWithWait") public void completedOperationWithWait( @WebParam(name = "Completed", targetNamespace = "http://docs.oasis-open.org/ws-tx/wsba/2006/06", partName = "parameters") NotificationType 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) ; } {code} 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

12 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues August 2013