[JBoss JIRA] Created: (JBTM-663) MissingResourceException when synchronizing a JTA transaction
by Olivier BILLIARD (JIRA)
MissingResourceException when synchronizing a JTA transaction
-------------------------------------------------------------
Key: JBTM-663
URL: https://jira.jboss.org/jira/browse/JBTM-663
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JTA
Affects Versions: 4.8.0, 4.5.0
Environment: AS 5.0.1 GA
Reporter: Olivier BILLIARD
In the class "com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple"
When we try to synchronize to an aborted JTA transaction a RollbackException is thrown. This exception is catched and we throw a RuntimeException using the key "com.arjuna.ats.internal.jta.transaction.arjunacore.syncrollbackmexception".
This key doesn't exist in the jta_msg_en_US.properties file. It seems to me that the end of the key should be syncrollbackexception because this key exist in the file.
I attach the corrected 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
14 years, 11 months
[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-662) placate maven users
by Jonathan Halliday (JIRA)
placate maven users
-------------------
Key: JBTM-662
URL: https://jira.jboss.org/jira/browse/JBTM-662
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Build System
Affects Versions: 4.8.0
Reporter: Jonathan Halliday
Assignee: Jonathan Halliday
Fix For: 4.9.0
It seems that fear and loathing of mvn is not as widespread as one may expect. Therefore, improve the build packaging process to provide more loquacious poms and such, whilst continuing to avoid using mvn for the actual build in the interests of preserving developer sanity.
--
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
[JBoss JIRA] Created: (JBTM-660) Instrument the Object Store via JMX
by Michael Musgrove (JIRA)
Instrument the Object Store via JMX
-----------------------------------
Key: JBTM-660
URL: https://jira.jboss.org/jira/browse/JBTM-660
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Tooling
Affects Versions: 4.6.1
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 4.9.0
JBossTS tooling suffers from a number of drawbacks:
- it only supports local access;
- it cannot be easily migrated to JOPR
- it is a propriety management solution.
This feature request is the first in a series for migrating the tooling to a JMX based solution.
The existing tooling should only be removed when all tools have been migrated.
--
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
[JBoss JIRA] Created: (JBTM-605) subordinate tx core commit fails are not passed to JTA layer
by Jonathan Halliday (JIRA)
subordinate tx core commit fails are not passed to JTA layer
------------------------------------------------------------
Key: JBTM-605
URL: https://jira.jboss.org/jira/browse/JBTM-605
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA
Affects Versions: 4.7.0
Reporter: Jonathan Halliday
Assignee: Mark Little
Fix For: 4.8.0
Where commit on an XAResourceRecord fails in such as way as to return TwoPhaseOutcome.FINISH_ERROR, no error is seen at the JTA (actually JCA XATerminator) layer, effectively making the commit failure invisible except by reading the WARN in the log files. Core does not consider this situation a heuristic, as with a single record there is no inconsistency as such. However, to a user it is an error - they asked for a commit but got a rollback.
--
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