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 …
[View More]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
[View Less]
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 …
[View More](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
[View Less]
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.…
[View More]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
[View Less]
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: …
[View More]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
[View Less]
[ 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 …
[View More]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
[View Less]
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.
-
…
[View More]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
[View Less]
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
…
[View More]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
[View Less]
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
…
[View More]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
[View Less]
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
…
[View More] 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
[View Less]