May 2008 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-363) Do check for LRCO earlier in enlistResource

by Mark Little (JIRA)

Do check for LRCO earlier in enlistResource ------------------------------------------- Key: JBTM-363 URL: http://jira.jboss.com/jira/browse/JBTM-363 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation, JTS Implementation Affects Versions: 4.3.0.GA Reporter: Mark Little We check for Last Resource at the end of enlistResource, when we have already called start on the resource (and done a lot of other work). It would be better to do this check earlier, so if we have to exit we can do so before having touched the resource at all. -- 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, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBTM-362) add failure does not cause rollback/end

by Mark Little (JIRA)

add failure does not cause rollback/end --------------------------------------- Key: JBTM-362 URL: http://jira.jboss.com/jira/browse/JBTM-362 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation, JTS Implementation Affects Versions: 4.3.0.GA Reporter: Mark Little BasicAction.add always assumes that a failure to add means the parameter (the participant) is tidied up by the caller if necessary. enlistResource doesn't do that, when it should: start has been called on the participant by the time BasicAction.add is called, which means that a failure at this stage needs end to be called. The transaction is going to be rolled back anyway, so nothing else needs to be done. -- 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, 11 months

2
6
0 / 0

[JBoss JIRA] Created: (JBTM-367) remove spurious error log statement from XAResourceRecord

by Jonathan Halliday (JIRA)

remove spurious error log statement from XAResourceRecord --------------------------------------------------------- Key: JBTM-367 URL: http://jira.jboss.com/jira/browse/JBTM-367 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.2.3.CP01, 4.2.3.SP7 Reporter: Jonathan Halliday Assigned To: Jonathan Halliday Fix For: 4.2.3.SP8, 4.2.3.CP02 "System.err.println("**recoveryModules "+recoveryModules);" crept in the code base. This was for dev debug only and should be purged. -- 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, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-289) remove use of Synchronizations for lock storage in jboss integration

by Jonathan Halliday (JIRA)

remove use of Synchronizations for lock storage in jboss integration -------------------------------------------------------------------- Key: JBTM-289 URL: http://jira.jboss.com/jira/browse/JBTM-289 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP5 Reporter: Jonathan Halliday Assigned To: Jonathan Halliday Fix For: 4.2.3.SP6 JBossAS needs to be able to lock transactions regardless of their state. Since the current integration implementation uses Synchronizations to store lock state, locking is possible only during transactions lifecycle phases where Synchronization registration is permitted. Relax this by changing the integration so that locks are stored using the general object storage mechanism added to TransactionImple to support JTA 1.1. -- 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, 11 months

1
6
0 / 0

[JBoss JIRA] Closed: (JBTM-18) Use inhouse DTF for QA

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-18?page=all ] Mark Little closed JBTM-18. --------------------------- Fix Version/s: 4.4.CR1 (was: 4.4) Resolution: Done Assignee: Mark Little (was: Richard Achmatowicz) Done and running for the past few weeks. > Use inhouse DTF for QA > ---------------------- > > Key: JBTM-18 > URL: http://jira.jboss.com/jira/browse/JBTM-18 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTA Implementation, JTS Implementation, WS-T Implementation > Reporter: Mark Little > Assigned To: Mark Little > Fix For: 4.4.CR1 > > > Get the QA up and running for refactored ATS. Require refactoring DTF too. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-319) Update JNDI recovery to cope with WrappedDataSource

by Mark Little (JIRA)

Update JNDI recovery to cope with WrappedDataSource --------------------------------------------------- Key: JBTM-319 URL: http://jira.jboss.com/jira/browse/JBTM-319 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation, Recovery Affects Versions: 4.2.3.SP6 Reporter: Mark Little -- 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, 11 months

3
13
0 / 0

[JBoss JIRA] Created: (JBTM-364) IndirectRecoverableConnection<ctor>() should not setup datasource

by Jonathan Halliday (JIRA)

IndirectRecoverableConnection<ctor>() should not setup datasource ----------------------------------------------------------------- Key: JBTM-364 URL: http://jira.jboss.com/jira/browse/JBTM-364 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation, Recovery Affects Versions: 4.3.0.GA, 4.2.3.SP7 Reporter: Jonathan Halliday Assigned To: Jonathan Halliday Fix For: 4.2.3.SP8, 4.4.CR1 The default constructor for IndirectRecoverableConnection attempts to use a null variable as input to the datasource setup fn. This naturally fails horribly. The default ctor should not attempt the setup, it's not possible until the datasource name is set. The datasource will be inited lazily on demand, so removing the setup attempt from the ctor is not a problem. -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-361) xa_start failures should still cause addition of new RM to participant list

by Mark Little (JIRA)

xa_start failures should still cause addition of new RM to participant list --------------------------------------------------------------------------- Key: JBTM-361 URL: http://jira.jboss.com/jira/browse/JBTM-361 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation, JTS Implementation Affects Versions: 4.3.0.GA Reporter: Mark Little For a new RM we call start and then add it to the list of participants. OK if there are no errors, but xa_start could throw an exception. Although we catch that exception and rollback the tx, the resource in question has not been added to the list of participants so doesn't get the resultant xa_end/xa_rollback invocation. The addition of the entry to the participant list should be in a finally block within TransactionImple. (Check JTS too.) -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-279) Find the JBossMQ recovery code and make sure it's shipped in the next release of AS.

by Mark Little (JIRA)

Find the JBossMQ recovery code and make sure it's shipped in the next release of AS. ------------------------------------------------------------------------------------ Key: JBTM-279 URL: http://jira.jboss.com/jira/browse/JBTM-279 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: Jonathan Halliday Priority: Blocker Adrian did some work on providing a ResourceRecovery implementation and RecoveryModule for JBossMQ (for Glencore). I had assumed that support would make sure it was shipped in subsequent releases of AS (since recovery is pretty important), but that doesn't seem to be the case. If they are not going to do it, then we need to because MQ is effectively frozen (at least that's what Adrian thought). -- 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, 11 months

4
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues May 2008