August 2013 - jbossts-issues - Jboss List Archives

[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, 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. 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 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: {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

10 years, 9 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: ------------------------------------- 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: {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

10 years, 9 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 updated JBTM-1718: -------------------------------- Original Estimate: (was: 3 days) Remaining Estimate: (was: 3 days) > 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

10 years, 9 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 updated JBTM-1718: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > 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 > Priority: Minor > Fix For: 5.0.0.M5 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > 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

10 years, 9 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 updated JBTM-1718: -------------------------------- Priority: Major (was: Minor) > 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 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > 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

10 years, 9 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 updated JBTM-1718: -------------------------------- Fix Version/s: 5.0.0.M4 (was: 5.0.0.M5) > 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 > Priority: Minor > Fix For: 5.0.0.M4 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-396) Provide one-phase commit optimization for WS-TX

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-396?page=com.atlassian.jira.plugin.s... ] Paul Robinson commented on JBTM-396: ------------------------------------ Mark, I've added the forum link to the description. I've also checked for duplicate issues in Jira, and I can't find any. > Provide one-phase commit optimization for WS-TX > ----------------------------------------------- > > Key: JBTM-396 > URL: https://issues.jboss.org/browse/JBTM-396 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: XTS > Affects Versions: 4.4.CR1 > Reporter: Mark Little > Assignee: Paul Robinson > > WS-AT does not support 1PC optimization. WS-ACID from WS-CAF does. It would be good to provide a configurable option for WS-AT users to enable 1PC optimization. This obviously breaks interoperability, which is why the default should be to have it disabled. > Discussion currently happening here: https://community.jboss.org/message/831313 -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-396) Provide one-phase commit optimization for WS-TX

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-396?page=com.atlassian.jira.plugin.s... ] Paul Robinson updated JBTM-396: ------------------------------- Description: WS-AT does not support 1PC optimization. WS-ACID from WS-CAF does. It would be good to provide a configurable option for WS-AT users to enable 1PC optimization. This obviously breaks interoperability, which is why the default should be to have it disabled. Discussion currently happening here: https://community.jboss.org/message/831313 was:WS-AT does not support 1PC optimization. WS-ACID from WS-CAF does. It would be good to provide a configurable option for WS-AT users to enable 1PC optimization. This obviously breaks interoperability, which is why the default should be to have it disabled. > Provide one-phase commit optimization for WS-TX > ----------------------------------------------- > > Key: JBTM-396 > URL: https://issues.jboss.org/browse/JBTM-396 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: XTS > Affects Versions: 4.4.CR1 > Reporter: Mark Little > Assignee: Paul Robinson > > WS-AT does not support 1PC optimization. WS-ACID from WS-CAF does. It would be good to provide a configurable option for WS-AT users to enable 1PC optimization. This obviously breaks interoperability, which is why the default should be to have it disabled. > Discussion currently happening here: https://community.jboss.org/message/831313 -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1872) com.jboss.transaction.wstf.interop.Sc007Test.test3_4 failed with TransactionRolledBackException

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1872?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-1872: ---------------------------- Fix Version/s: 5.0.0.M4 > com.jboss.transaction.wstf.interop.Sc007Test.test3_4 failed with TransactionRolledBackException > ----------------------------------------------------------------------------------------------- > > Key: JBTM-1872 > URL: https://issues.jboss.org/browse/JBTM-1872 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing, XTS > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 4.17.8, 5.0.0.M4 > > > http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP61-jdbcobjectst... > {noformat} > 19:15:34,794 ERROR [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-1-thread-1) Failed: com.jboss.transaction.wstf.interop.Sc007Test.test3_4: com.arjuna.wst.TransactionRolledBackException > at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:65) [jbossxts-4.17.8.Final-SNAPSHOT.jar:4.17.8.Final-SNAPSHOT] > at com.jboss.transaction.wstf.interop.Sc007TestCase.test3_4(Sc007TestCase.java:283) [classes:] > at com.jboss.transaction.wstf.interop.Sc007Test.test3_4(Sc007Test.java:130) [classes:] > {noformat} -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1872) com.jboss.transaction.wstf.interop.Sc007Test.test3_4 failed with TransactionRolledBackException

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1872?page=com.atlassian.jira.plugin.... ] Amos Feng resolved JBTM-1872. ----------------------------- Resolution: Duplicate Issue > com.jboss.transaction.wstf.interop.Sc007Test.test3_4 failed with TransactionRolledBackException > ----------------------------------------------------------------------------------------------- > > Key: JBTM-1872 > URL: https://issues.jboss.org/browse/JBTM-1872 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing, XTS > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 4.17.8, 5.0.0.M4 > > > http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP61-jdbcobjectst... > {noformat} > 19:15:34,794 ERROR [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-1-thread-1) Failed: com.jboss.transaction.wstf.interop.Sc007Test.test3_4: com.arjuna.wst.TransactionRolledBackException > at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:65) [jbossxts-4.17.8.Final-SNAPSHOT.jar:4.17.8.Final-SNAPSHOT] > at com.jboss.transaction.wstf.interop.Sc007TestCase.test3_4(Sc007TestCase.java:283) [classes:] > at com.jboss.transaction.wstf.interop.Sc007Test.test3_4(Sc007Test.java:130) [classes:] > {noformat} -- 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

10 years, 9 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 August 2013