March 2009 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-237) NORMAL mode for TransactionReaper sets checking period based on transaction timeout and not property

by Mark Little (JIRA)

NORMAL mode for TransactionReaper sets checking period based on transaction timeout and not property ---------------------------------------------------------------------------------------------------- Key: JBTM-237 URL: http://jira.jboss.com/jira/browse/JBTM-237 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Mark Little In the insert method the sleep period for the transaction reaper thread is continually modified to be based on the least timeout associated with the transaction added. This is fine for DYNAMIC mode, but is contrary to what NORMAL is supposed to do: scan based purely on the default scan timeout period specified in the configuration file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

2
7
0 / 0

[JBoss JIRA] Created: (JBTM-226) Possible race condition between top-down and bottom-up recovery

by Mark Little (JIRA)

Possible race condition between top-down and bottom-up recovery --------------------------------------------------------------- Key: JBTM-226 URL: http://jira.jboss.com/jira/browse/JBTM-226 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP4 Environment: Mac OS X, JDK 1.4.2. Reporter: Mark Little Assigned To: Mark Little Priority: Critical In local JTA recovery for non-serializable XAResources, the XAResourceRecovery implementation is needed to obtain a new XAResource. If a new resource isn't obtained (because the XAResourceRecovery instances haven't all been triggered yet), top-down recovery retries on subsequent recovery sweeps. Meanwhile, bottom up recovery can kick in and use an XAResource from a XAResourceRecovery that is now available and fail to locate any information on the transaction that will drive it top-down. Upon failing to find the transaction, it uses presumed abort and rolls back the instance, when in fact it should wait and commit it. But it doesn't do that until several phases have passed, and in which case most of the time top-down recovery will have re-run, found the XAResource and committed the transaction. I'm fairly sure this is a race condition and does exist, but am still checking. Work around exists at the moment though. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

3
9
0 / 0

[JBoss JIRA] Created: (JBTM-298) There is no way for recovery through JCA to indicate temporary failure to recover

by Mark Little (JIRA)

There is no way for recovery through JCA to indicate temporary failure to recover --------------------------------------------------------------------------------- Key: JBTM-298 URL: http://jira.jboss.com/jira/browse/JBTM-298 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.4 This means client-driven recovery sees a failure to recover and doesn't try again. We should give a "try again later" option (XA_RETRY). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (JBTM-432) Authentication support on AppServerJDBCXARecovery plugin

by Tyronne Wickramarathne (JIRA)

Authentication support on AppServerJDBCXARecovery plugin -------------------------------------------------------- Key: JBTM-432 URL: https://jira.jboss.org/jira/browse/JBTM-432 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.2.3.SP5 Environment: JBoss-EAP-4.3_CP3, jdk 1.5.0_15-b04 Reporter: Tyronne Wickramarathne The present implementation of AppServerJDBCXARecovery plugin has a limitation on its usage when the invokers are secured. Hence, to overcome this limitation AppServerJDBCXARecovery plugin has to support authentication so this could be used even when the invokers are secured. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

4
12
0 / 0

[JBoss JIRA] Created: (JBTM-329) When BridgeParticipantAT receives prepare, participant should associate current thread with corresponding JTA transaction

by Pavel Kadlec (JIRA)

When BridgeParticipantAT receives prepare, participant should associate current thread with corresponding JTA transaction ------------------------------------------------------------------------------------------------------------------------- Key: JBTM-329 URL: http://jira.jboss.com/jira/browse/JBTM-329 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBoss-4.2.1.GA, JBossTS-4.2.3.SP7 Reporter: Pavel Kadlec When participant receives prepare from coordinator, it calls prepare on jta transaction. SubordinateAtomicAction.doPrepare then calls beforeCompletion() method. Hibernate registers Synchronization object which is called in beforeCompletion() method. In that synchronization object, when hibernate cannot find transaction on current thread, it flushes all entites into database, which is bad. When Hibernate cannot find transaction on thread, it logs WARN [AbstractEntityManagerImpl] Transaction not available on beforeCompletionPhase: assuming valid Fix is easy, BridgeParticipantAT should associate current thread with the corresponding JTA transaction. And finally it should suspend that JTA transaction. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (JBTM-484) Transaction timeout notifier

by Mark Little (JIRA)

Transaction timeout notifier ---------------------------- Key: JBTM-484 URL: https://jira.jboss.org/jira/browse/JBTM-484 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.5 Reporter: Mark Little Assignee: Mark Little Fix For: 4.7 Provide a means whereby listeners can be informed of timeouts. Should try to work with rollback-only too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-230) Put xaRecoveryNode in configuration

by Mark Little (JIRA)

Put xaRecoveryNode in configuration ----------------------------------- Key: JBTM-230 URL: http://jira.jboss.com/jira/browse/JBTM-230 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP4 Reporter: Mark Little Assigned To: Mark Little Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (JBTM-438) Consider flattening the property file (again)

by Mark Little (JIRA)

Consider flattening the property file (again) --------------------------------------------- Key: JBTM-438 URL: https://jira.jboss.org/jira/browse/JBTM-438 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Configuration Affects Versions: 4.4.0.GA Reporter: Mark Little Assignee: Mark Little At one time the configuration file was relatively straightforward. Then we added support for nested scopes and dependencies between scopes. This is overkill these days, so we should consider going back to a nice straightforward property file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBTM-235) Check thread creation for context inheritance

by Kevin Conner (JIRA)

Check thread creation for context inheritance --------------------------------------------- Key: JBTM-235 URL: http://jira.jboss.com/jira/browse/JBTM-235 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Reporter: Kevin Conner Assigned To: Mark Little All threads created in the transaction manager should be checked to make sure they are not inheriting anything unexpected (classloader/thread locals etc) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

4
9
0 / 0

[JBoss JIRA] Created: (JBTM-503) Shutdown the ExpiredEntryMonitor when stopping the RecoveryManager

by Mauro Molinari (JIRA)

Shutdown the ExpiredEntryMonitor when stopping the RecoveryManager ------------------------------------------------------------------ Key: JBTM-503 URL: https://jira.jboss.org/jira/browse/JBTM-503 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 4.5 Environment: Tomcat + Spring + DBCP + JBossJTA Reporter: Mauro Molinari When the recovery manager is started, the implementation RecoveryManagerImple starts the ExpiredEntryMonitor. When you stop the recovery manager, however, the ExpiredEntryMonitor is not shut down. On line 250 of com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple there's the line ExpiredEntryMonitor.shutdown() commented out, with a "TODO why?" comment immediately before. I don't know exactly what should be the lifecylce of ExpiredEntryMonitor versus that of RecoveryManagerImple, however I think that one of the following should happen: - ExpiredEntryMonitor is started when RecoveryManagerImple is started (rather than constructed), so that it is shut down when the RecoveryManagerImple is stopped OTHERWISE - RecoveryManagerImple provides a way to "dispose" or "disable" it and this includes the shutdown of ExpiredEntryMonitor OTHERWISE - it is documented that stopping the recovery manager needs the ExpiredEntryMonitor to be stopped too: however, please consider that com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.shutdown() throws a NullPointerException if called while the ExpiredEntryMonitor has not been started before and there is no public method to test if it has been started or not; so if I need to write some code that stops the ExpiredEntryMonitor (without knowing if it has been started or not) I have to write some ugly code like: {code:java} try { ExpiredEntryMonitor.shutdown(); } catch(final NullPointerException e) { // ExpiredEntryMonitor had not been started } {code} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

2
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues March 2009