March 2015 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability)

by Tomasz Krakowiak (JIRA)

[ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.... ] Tomasz Krakowiak updated JBTM-2350: ----------------------------------- Description: The problem is with availability of `UserTransaction`. Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal<Boolean>`. `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). Here's a story: We have a bean - `beanA` - with single method annotated transactional - `beanA.transactional()`. This method is being called from two threads, where: - Thread 1 is participating in BMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is true. - Thread 2 is participating in CMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is false. Both threads call `beanA.transactional()` at the same time. What may happen: 1. Thread 1 - enters method `beanA.transactional()`. Interceptor sets previousUserTransactionAvailability to true. 2. Thread 2 - enters method `beanA.transactional()`. Interceptor sets previousUserTransactionAvailability to false. 3. Thread 1 - exits method `beanA.transactional()` Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) was: The problem is with availability of `UserTransaction`. Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal<Boolean>`. `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). Here's a story: We have a bean (beanA) with single method annotated transactional (beanA.transactional()). This method is being called from two threads, where: - Thread 1 is participating in BMT, therefore it's ServerVMClientUserTransaction.isAvailables value is true. - Thread 2 is participating in CMT, therefore it's ServerVMClientUserTransaction.isAvailables value is false. Both threads call beanA.transactional() at the same time. What may happen: 1. Thread 1 - enters method beanA.transactional. Interceptor sets previousUserTransactionAvailability to true. 2. Thread 2 - enters method beanB.transactional. Interceptor sets previousUserTransactionAvailability to false. 3. Thread 1 - exits method beanA.transactional Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tom Jenkinson > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal<Boolean>`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean - `beanA` - with single method annotated transactional - `beanA.transactional()`. > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is true. > - Thread 2 is participating in CMT, therefore it's `ServerVMClientUserTransaction.isAvailables` value is false. > Both threads call `beanA.transactional()` at the same time. > What may happen: > 1. Thread 1 - enters method `beanA.transactional()`. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method `beanA.transactional()`. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method `beanA.transactional()` > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability)

by Tomasz Krakowiak (JIRA)

[ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.... ] Tomasz Krakowiak updated JBTM-2350: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/811 > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tom Jenkinson > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal<Boolean>`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean (beanA) with single method annotated transactional (beanA.transactional()). > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's ServerVMClientUserTransaction.isAvailables value is true. > - Thread 2 is participating in CMT, therefore it's ServerVMClientUserTransaction.isAvailables value is false. > Both threads call beanA.transactional() at the same time. > What may happen: > 1. Thread 1 - enters method beanA.transactional. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method beanB.transactional. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method beanA.transactional > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability)

by Tomasz Krakowiak (JIRA)

[ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.... ] Tomasz Krakowiak commented on JBTM-2350: ---------------------------------------- Use case: We are queuing some messages on JMS. We use our own JMS consumers which run in BMT. However submitting messages occurs in CMT. Both submitting and processing message use some DAO beans which use transactional annotations. I encountered this issue on production. I fixed it by hacking in SNAPSHOT into wildfly - it resolved the issue. I would write unit test for it, but I haven't figured out how to run narayana arquillian tests (-Parq). It requires some some additional parameters and configured environment i guess. > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tom Jenkinson > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal<Boolean>`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean (beanA) with single method annotated transactional (beanA.transactional()). > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's ServerVMClientUserTransaction.isAvailables value is true. > - Thread 2 is participating in CMT, therefore it's ServerVMClientUserTransaction.isAvailables value is false. > Both threads call beanA.transactional() at the same time. > What may happen: > 1. Thread 1 - enters method beanA.transactional. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method beanB.transactional. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method beanA.transactional > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability)

by Tomasz Krakowiak (JIRA)

[ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.... ] Tomasz Krakowiak edited comment on JBTM-2350 at 3/6/15 4:12 AM: ---------------------------------------------------------------- Use case: We are queuing some messages on JMS. We use our own JMS consumers which run in BMT. However submitting messages occurs in CMT. Both submitting and processing message use some DAO beans which use transactional annotations. I encountered this issue on production. I fixed it and hacked in my SNAPSHOT into wildfly - it resolved the issue. I would write unit test for it, but I haven't figured out how to run narayana arquillian tests (-Parq). It requires some some additional parameters and configured environment i guess. was (Author: niematojaktomasz): Use case: We are queuing some messages on JMS. We use our own JMS consumers which run in BMT. However submitting messages occurs in CMT. Both submitting and processing message use some DAO beans which use transactional annotations. I encountered this issue on production. I fixed it by hacking in SNAPSHOT into wildfly - it resolved the issue. I would write unit test for it, but I haven't figured out how to run narayana arquillian tests (-Parq). It requires some some additional parameters and configured environment i guess. > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tom Jenkinson > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal<Boolean>`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean (beanA) with single method annotated transactional (beanA.transactional()). > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's ServerVMClientUserTransaction.isAvailables value is true. > - Thread 2 is participating in CMT, therefore it's ServerVMClientUserTransaction.isAvailables value is false. > Both threads call beanA.transactional() at the same time. > What may happen: > 1. Thread 1 - enters method beanA.transactional. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method beanB.transactional. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method beanA.transactional > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability)

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2350: ---------------------------------------- Do you have a test case for this? I guess the easy fix is to make TransactionalInterceptorBase#previousUserTransactionAvailability a thread local too. > CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) > ----------------------------------------------------------------------------------------- > > Key: JBTM-2350 > URL: https://issues.jboss.org/browse/JBTM-2350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4 > Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X > Reporter: Tomasz Krakowiak > Assignee: Tom Jenkinson > > The problem is with availability of `UserTransaction`. > Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal<Boolean>`. > `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). > Here's a story: > We have a bean (beanA) with single method annotated transactional (beanA.transactional()). > This method is being called from two threads, where: > - Thread 1 is participating in BMT, therefore it's ServerVMClientUserTransaction.isAvailables value is true. > - Thread 2 is participating in CMT, therefore it's ServerVMClientUserTransaction.isAvailables value is false. > Both threads call beanA.transactional() at the same time. > What may happen: > 1. Thread 1 - enters method beanA.transactional. > Interceptor sets previousUserTransactionAvailability to true. > 2. Thread 2 - enters method beanB.transactional. > Interceptor sets previousUserTransactionAvailability to false. > 3. Thread 1 - exits method beanA.transactional > Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability)

by Tomasz Krakowiak (JIRA)

Tomasz Krakowiak created JBTM-2350: -------------------------------------- Summary: CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability) Key: JBTM-2350 URL: https://issues.jboss.org/browse/JBTM-2350 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.0.4, 5.0.3, 5.0.2, 5.0.1, 5.0.0 Environment: Wildfly 8.1.0, Wildfly 8.2.0, linux, OS X Reporter: Tomasz Krakowiak Assignee: Tom Jenkinson The problem is with availability of `UserTransaction`. Availability of UserTransaction is stored in `ServerVMClientUserTransaction.isAvailables` which is `ThreadLocal<Boolean>`. `TransactionalInterceptorRequired` when intercepting call, stores thread local value of `isAvailables` in `TransactionalInterceptorBase.previousUserTransactionAvailability` field of interceptor - which is of type boolean(not thread local). Here's a story: We have a bean (beanA) with single method annotated transactional (beanA.transactional()). This method is being called from two threads, where: - Thread 1 is participating in BMT, therefore it's ServerVMClientUserTransaction.isAvailables value is true. - Thread 2 is participating in CMT, therefore it's ServerVMClientUserTransaction.isAvailables value is false. Both threads call beanA.transactional() at the same time. What may happen: 1. Thread 1 - enters method beanA.transactional. Interceptor sets previousUserTransactionAvailability to true. 2. Thread 2 - enters method beanB.transactional. Interceptor sets previousUserTransactionAvailability to false. 3. Thread 1 - exits method beanA.transactional Interceptor restores thread local value of `isAvailables` to false (leaked value from thread 2!) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2349) CompensationContext is destroyed once the first handler is invoked

by Gytis Trikleris (JIRA)

Gytis Trikleris created JBTM-2349: ------------------------------------- Summary: CompensationContext is destroyed once the first handler is invoked Key: JBTM-2349 URL: https://issues.jboss.org/browse/JBTM-2349 Project: JBoss Transaction Manager Issue Type: Bug Components: TXFramework Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Critical Fix For: 5.0.5 https://github.com/jbosstm/narayana/blob/master/compensations/src/main/ja... https://github.com/jbosstm/narayana/blob/master/compensations/src/main/ja... If there are two handlers (compensation or confirmation), which need to access the same compensation scoped object, only the first one will succeed. Once the first handler is invoked from the ParticipantImpl, CompensationScope is destroyed. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2347) Make JMH perf benchmark failure threshold configurable

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2347?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2347: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Make JMH perf benchmark failure threshold configurable > ------------------------------------------------------ > > Key: JBTM-2347 > URL: https://issues.jboss.org/browse/JBTM-2347 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Performance Testing > Affects Versions: 5.0.4 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > The PERF profile for PR testing (added in JBTM-2337) fails a job if the performance of any test degrades by more than 10%. The threshold needs to be configurable. > Additionally change test com.hp.mwtests.ts.arjuna.performance.Performance1 so that it does at least some work (the test is so trivial that it's possibly prone to anomalous timings). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2348) No CI job for testing git pull requests against the benchmark perf repo

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2348?page=com.atlassian.jira.plugin.... ] Michael Musgrove resolved JBTM-2348. ------------------------------------ Resolution: Done The new CI job is btny-pulls-benchmark (and the poller btny-pulls-benchmark-poller) > No CI job for testing git pull requests against the benchmark perf repo > ----------------------------------------------------------------------- > > Key: JBTM-2348 > URL: https://issues.jboss.org/browse/JBTM-2348 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > There is no CI job for testing PRs against the benchmarks in the performance repo https://github.com/jbosstm/performance/narayana repo -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2347) Make JMH perf benchmark failure threshold configurable

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2347?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2347: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/performance/pull/5 > Make JMH perf benchmark failure threshold configurable > ------------------------------------------------------ > > Key: JBTM-2347 > URL: https://issues.jboss.org/browse/JBTM-2347 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Performance Testing > Affects Versions: 5.0.4 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > The PERF profile for PR testing (added in JBTM-2337) fails a job if the performance of any test degrades by more than 10%. The threshold needs to be configurable. > Additionally change test com.hp.mwtests.ts.arjuna.performance.Performance1 so that it does at least some work (the test is so trivial that it's possibly prone to anomalous timings). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 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 March 2015