[JBoss JIRA] (JBTM-2387) Async Abort
by Mark Little (JIRA)
Mark Little created JBTM-2387:
---------------------------------
Summary: Async Abort
Key: JBTM-2387
URL: https://issues.jboss.org/browse/JBTM-2387
Project: JBoss Transaction Manager
Issue Type: Feature Request
Components: Transaction Core
Affects Versions: 5.1.1
Reporter: Mark Little
Assignee: Mark Little
Async prepare and commit always made sense. Rollback was something we'd add when/if there was a good scenario. Vert.x may well be that scenario, though see linked issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (JBTM-2350) CDI Transactional interceptors are not thread safe. (previousUserTransactionAvailability)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2350?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2350.
-------------------------------
> 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: Tomasz Krakowiak
> Fix For: 5.1.0
>
>
> 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.15#6346)
9 years, 7 months
[JBoss JIRA] (JBTM-2333) Blacktie subsystem build fails, because of missing org.jacorb module
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2333?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2333.
-------------------------------
> Blacktie subsystem build fails, because of missing org.jacorb module
> --------------------------------------------------------------------
>
> Key: JBTM-2333
> URL: https://issues.jboss.org/browse/JBTM-2333
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Application Server Integration, BlackTie
> Reporter: Gytis Trikleris
> Assignee: Amos Feng
> Priority: Blocker
> Fix For: 5.1.0
>
>
> http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/731/
> {code}
> [ERROR] Failed to execute goal org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1.0.0.Alpha8:build (feature-pack-build) on project wildfly-blacktie-feature-pack: Execution feature-pack-build of goal org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1.0.0.Alpha8:build failed: java.lang.RuntimeException: Some errors were encountered creating the feature pack
> [ERROR] Missing module ModuleIdentifier{name='org.jacorb', slot='main'}. Module was required by [ModuleIdentifier{name='org.wildfly.extension.blacktie', slot='main'}]
> [ERROR] -> [Help 1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (JBTM-2342) Add callbacks for thread-to-transaction association changes
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2342?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2342.
-------------------------------
> Add callbacks for thread-to-transaction association changes
> -----------------------------------------------------------
>
> Key: JBTM-2342
> URL: https://issues.jboss.org/browse/JBTM-2342
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: Application Server Integration
> Affects Versions: 5.0.4
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.1.0
>
>
> This feature calls for a mechanism to avoid issues around concurrent access to a JPA EM if a transaction times out. Currently EM cleanup happens in AC callbacks - if those callbacks happen on the application thread there is no issue but if they happen on the reaper thread then it is possible for the EM to be manipulated whilst the application is still using it.
> The linked forum thread came up with 4 proposals to handle the problem:
> # Reaper marks transaction as set rollback only: this solution has potentially insurmountable issues (eg JVM1 -> JVM2, JVM1 crashes, txn never gets commit/rollback called on it). In addition it would need to be configurable - some users want the reaper to do the timely rollback;
> # WildFly wraps the TM/TSR and coordinates the running of all Synchronization callbacks. This solution is complex and does the AS have sufficient knowledge to coordinate callbacks correctly. Option 4 below is similar but the decision about what to do and when to do it is left in the hands of the relevant callbacks where the knowlege resides;
> # Start a discussion on the JPA expert group to get certain thread unsafe Synchronization JPA callbacks used by EE container/Persistence providers changed. This is an option for the future;
> # Trigger callbacks when the transaction is disassociated from a thread. For example, detaching any loaded entities and closing the EM can be done when all relevant callbacks, namely the afterCompletion callback (triggered on the reaper thread) and the txn disassociated callback (triggered on the application thread) have been seen.
> This JIRA will implement option 4.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (JBTM-2347) Make JMH perf benchmark failure threshold configurable
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2347?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2347.
-------------------------------
> Make JMH perf benchmark failure threshold configurable
> ------------------------------------------------------
>
> Key: JBTM-2347
> URL: https://issues.jboss.org/browse/JBTM-2347
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Performance Testing
> Affects Versions: 5.0.4
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.1.0
>
>
> 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.15#6346)
9 years, 7 months