February 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2859) Transaction bridging for REST-AT not working because of switch to new wfly transaction client

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-2859: ----------------------------------- Summary: Transaction bridging for REST-AT not working because of switch to new wfly transaction client Key: JBTM-2859 URL: https://issues.jboss.org/browse/JBTM-2859 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.5.2.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Blocker Transaction bridging (RTS <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). The cause code change could be checked here https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b... Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2858) Transaction bridging for REST-AT not working because of switch to new wfly transaction client

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2858?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2858: -------------------------------- Component/s: REST (was: TxBridge) > Transaction bridging for REST-AT not working because of switch to new wfly transaction client > --------------------------------------------------------------------------------------------- > > Key: JBTM-2858 > URL: https://issues.jboss.org/browse/JBTM-2858 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Transaction bridging (RTS <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b... > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2858) Transaction bridging for REST-AT not working because of switch to new wfly transaction client

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2858?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2858: -------------------------------- Summary: Transaction bridging for REST-AT not working because of switch to new wfly transaction client (was: Transaction bridging for WS not working because of switch to new wfly transaction client) > Transaction bridging for REST-AT not working because of switch to new wfly transaction client > --------------------------------------------------------------------------------------------- > > Key: JBTM-2858 > URL: https://issues.jboss.org/browse/JBTM-2858 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b... > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. > Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2858) Transaction bridging for REST-AT not working because of switch to new wfly transaction client

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2858?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2858: -------------------------------- Description: Transaction bridging (RTS <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). The cause code change could be checked here https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b... Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. was: Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). The cause code change could be checked here https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b... Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. > Transaction bridging for REST-AT not working because of switch to new wfly transaction client > --------------------------------------------------------------------------------------------- > > Key: JBTM-2858 > URL: https://issues.jboss.org/browse/JBTM-2858 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > Transaction bridging (RTS <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b... > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2858) Transaction bridging for WS not working because of switch to new wfly transaction client

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-2858: ----------------------------------- Summary: Transaction bridging for WS not working because of switch to new wfly transaction client Key: JBTM-2858 URL: https://issues.jboss.org/browse/JBTM-2858 Project: JBoss Transaction Manager Issue Type: Bug Components: TxBridge Affects Versions: 5.5.2.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Blocker Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). The cause code change could be checked here https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b... Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2846: -------------------------------- Fix Version/s: 5.next > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2846: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2846: ------------------------------------- actionStatus is kind of data. I don't think it would deadlock, it might hold it up if the TX is already in the process of completing but that wouldn't be undesirable either. > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.... ] David Lloyd commented on JBTM-2846: ----------------------------------- You are right, but with this approach a different problem occurs. The lock which is held during state changes would prevent setRollbackOnly from working during subordinate synchronization execution. This is an example of why synchronization should generally protect data, not code. > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2857) Investigate XTS outbound bridge potential nullpointer issue

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created JBTM-2857: ------------------------------------- Summary: Investigate XTS outbound bridge potential nullpointer issue Key: JBTM-2857 URL: https://issues.jboss.org/browse/JBTM-2857 Project: JBoss Transaction Manager Issue Type: Task Components: XTS Affects Versions: 5.5.2.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor During working on JBTM-2853 it was found `NullPointer` could be potentially thrown from `OutboundBridgeManager` when `getTransaction()` returns `null`. It's at time when thread is not associated with any txn. Discussion about this at PR: https://github.com/jbosstm/narayana/pull/1133 ``` Transaction transaction = (Transaction)TransactionManager.transactionManager().getTransaction(); ``` https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/or... Goal is to investigate this potential exception being trouble or not and if such thing could happen or not. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 2 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 February 2017