JBoss.orgCommunity Documentation
Abstract
Release notes for ArjunaCore, ArjunaJTA, ArjunaJTS, and XTS components of the JBoss Transaction Manager.
New features
TBD
ObjStoreBrowserMBean.
Originally, ObjStoreBrowserMBean was only known to support file-based
ObjectStores. It now implements the ObjectStoreAPI, and works with all types of ObjectStores supported by
the API.
Resolved issues
RollbackException now behaves as it did in JBoss Application Server
4.3 and earlier, providing debugging information about the cause of the exception.
In JBoss Application Server 4.2 and previous, when a transaction rolled back, the
RollbackException included the root cause of the exception. In JBoss Application
Server 5.1, the exception no longer included this information, even though the information can still be
found in a different area of the log file. Code which relied on the root cause information included in the
exception no longer worked as expected.
The debugging information has been put back into the exception, so that it works as it did previously. The following algorithm is used:
If setRollbackOnly() is called before commit(), the
initCause is setRollbackOnly called from..., regardless of
anything that may go wrong during the commit. beforeCompletions are not
called.
If getDeferredThrowable is not null, the
initCause is the deferredThrowable, even if
setRollbackOnly is also called before the exception is received.
If setRollbackOnly was called, it is the root cause. This covers the case where
a beforeCompletion calls setRollbackOnly but does not
throw an exception.
This fix allows you to code against the root cause of the RollbackException.
ObjectFactory.
TSR implementations have been modified to implement ObjectFactory.
StateManager.
The StateManager no longer includes the finalizer.
Removing threads operating on AsyncStore did not check to see if the cache was full, and did not notify AsyncCache to wake up. This could cause a stalling condition, if there were more removes than adds to the cache. Removes now check to see if the cache is full, and notify AsyncCache accordingly.
New features
UserTransaction is now serializable and referencable, in compliance wtih
the JTA.
The Java Transactions API (JTA) specifies that UserTransaction needs to be
serializable and referenceable. JBossTA now complies with this requirement.
Resolved issues
The threads in the transaction reaper, reaper worker, action store scanner, and the XTS reaper worker have been given names. This makes them easier to identify during profiling.
New features
XTS service and initialization classes are now packaged into a separate JAR, to make it easier to deploy XTS into other application servers, such as Tomcat.
In the past, WS-C and WS-T service endpoint URLs were hard-coded to conform to the pattern
http://. This
made it more difficult to deploy these services in different application servers. The path portion of the
URLs of the service endpoints are now configurable.
bindAddress:bindPort/war-name/service-name
Resolved issues
WS-BA 0.2.1 only imported the WST 1.0-compliant class libraries, and required a patch to import the WST
1.1-compliant class libraries. The BA framework now includes a libs/ directory that
hosts the WST 1.1-compliant libraries, so WST 1.0 and 1.1 are both supported in the default configuration.
The configuration instructions for deploying just the Coordinator component of XTS used to cause an exception, because the ATParticipantRecoveryModule was not available on the Participant component. he Participant and Coordinator recovery modules now create and install a manager if one is not already found, and the exception is no longer thrown.
The WSDLs have been removed from the WS-TX JAR. Both the WS-C and WS-TX JAR are needed by XTS, and the duplicate information was causing confusion without serving a purpose.
An invalid state SOAP fault causes the participant to be compensated, but the log message used to report that was cancelled. This has been fixed, so that the log message now agrees with the actual action.
The threads in the transaction reaper, reaper worker, action store scanner, and the XTS reaper worker have been given names. This makes them easier to identify during profiling.
Resolved issues
If the ORB was unable to bind to the specified port, it would print a warning to standard output and remain in an unusable state. No exception was thrown and there was no mechanism for making the ORB try again to bind to the port. The ORB now throws an exception and the developer can make the ORB try again to bind to the port.
The threads in the transaction reaper, reaper worker, action store scanner, and the XTS reaper worker have been given names. This makes them easier to identify during profiling.