August 2007 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-251) Check conformance and compatibility of two JTA implementations

by Mark Little (JIRA)

Check conformance and compatibility of two JTA implementations -------------------------------------------------------------- Key: JBTM-251 URL: http://jira.jboss.com/jira/browse/JBTM-251 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Andrew Dinn Make sure that both of our JTA implementations behave as similarly as possible from an interface perspective. For example, that timeouts are handled the same. Some differences are bound to be visible because the two implementations have different capabilities. But ignoring those, we need to be as consistent as possible. -- 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

14 years, 1 month

4
9
0 / 0

[JBoss JIRA] Created: (JBTM-229) Configurable exception throwing for multi-threaded environment

by Mark Little (JIRA)

Configurable exception throwing for multi-threaded environment -------------------------------------------------------------- Key: JBTM-229 URL: http://jira.jboss.com/jira/browse/JBTM-229 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JTA Implementation, JTS Implementation Reporter: Mark Little Assigned To: Mark Little Priority: Optional Currently if a thread A terminates a transaction in the same way as a thread B subsequently tries to, B will get an exception. This is to allow B to differentiate between it successfully terminating the transaction and someone else doing so. This comes from the OTS heritage. Maybe we should make it configurable, so deployments that couldn't care, can turn off that capability. -- 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

14 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-234) setRollbackOnly consistency

by Mark Little (JIRA)

setRollbackOnly consistency --------------------------- Key: JBTM-234 URL: http://jira.jboss.com/jira/browse/JBTM-234 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP4 Reporter: Mark Little Assigned To: Mark Little Priority: Optional OTS does not let you call rollback-only if the state of the transaction is not active. JTA doesn't make it clear whether or not that is an error. That makes it implementation dependent. At the moment both of our JTA implementations mask this issue. AS appears to not expect an exception from setRollbackOnly either, but that's may cause an issue if someone uses a different JTA. -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-236) Timeout references microseconds for periodicity when it should be milliseconds

by Mark Little (JIRA)

Timeout references microseconds for periodicity when it should be milliseconds ------------------------------------------------------------------------------ Key: JBTM-236 URL: http://jira.jboss.com/jira/browse/JBTM-236 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2.3.SP5 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, 3 months

2
6
0 / 0

[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, 3 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, 3 months

3
9
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-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, 5 months

4
9
0 / 0

[JBoss JIRA] Created: (JBTM-281) Make sure docs and web page information about supported JDBC drivers is up-to-date

by Mark Little (JIRA)

Make sure docs and web page information about supported JDBC drivers is up-to-date ---------------------------------------------------------------------------------- Key: JBTM-281 URL: http://jira.jboss.com/jira/browse/JBTM-281 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Jonathan Halliday Priority: Critical -- 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

2
3
0 / 0

[JBoss JIRA] Created: (JBTM-238) Add property to disable warning about multiple 1PC resources

by Mark Little (JIRA)

Add property to disable warning about multiple 1PC resources ------------------------------------------------------------ Key: JBTM-238 URL: http://jira.jboss.com/jira/browse/JBTM-238 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 Currently we always print a warning on multiple 1PC resources. Support for that has to be explicitly enabled. We print the warning in case the user set the wrong property, doesn't know the implications, forgot to set it back etc. For those users who never make mistakes and always know the implications, maybe we should have another property that basically means "only output warning once per VM run". -- 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

1
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues August 2007