[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
15 years
[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 month
[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
[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, 7 months
[JBoss JIRA] Created: (JBTM-257) Add more logging to participants when they fail
by Mark Little (JIRA)
Add more logging to participants when they fail
-----------------------------------------------
Key: JBTM-257
URL: http://jira.jboss.com/jira/browse/JBTM-257
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JTA Implementation, JTS Implementation, Transaction Core, WS-T Implementation
Affects Versions: 4.2.3.SP5
Reporter: Mark Little
Assigned To: Mark Little
Customer request:
"It would be very useful for us if the transaction manager would tell me on WARN level or INFO level which resource causes a roll back to happen. Applications run sometimes well for quite some time in PROD and suddenly there is a roll back and we have no hint why this happens."
--
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, 7 months