Fixed cleanup of resources when writing a new epoch file, to avoid exceptions under abnormal operating conditions.
Transactions with only 1 participant (or resource) will resort to 1-phase commit and there is no way to recover their state. Therefore, logging adds useless overhead and is now avoided.
We now try to avoid unnecessary and annoying HeuristicHazard outcomes and dito retries, by doing extra checks in the XAResource backend whenever possible.
Fixed a deadlock condition when multiple threads use the same JMS connection, each in its own session.
Fixed a NPE condition where concurrent borrow requests and close operations on existing sessions would interfere.
We've improved support for short properties that need to be converted from a text/XML configuration file.
The UserTransactionManager class has a class-level synchronized block used for init purposes. We've added extra checks so this block is only executed if really needed. This optimizes performance by limiting the number of cases where threads will block each other.
We've added a reset of the underlying ObjectOutputStream for serialized logging, to avoid high memory consumption when the JDK keeps pointers to all previously serialized objects since the last checkpoint.
Fixed a critical bug where errors on delist would cause connection pool exhaustion.
Empty, committing transactions would needlessly generate logging overhead and also generate needless heuristic warnings upon recovery. This has now been fixed. For the original report, see this forum post.
Committing 1PC transactions would be converted to heuristic hazard cases upon recovery, which is in fact incorrect because these will then undergo 2PC commit retry. This has now been fixed: committing 1PC transactions are now simply forgotten upon recovery.
Improved synchronization to avoid race conditions while checking whether or not a connection is taking part in a transaction. Also see this report in the forums.
Fixed polluting Mockito dependency in the poms.
Removed top-level folders that make unzipping to artifactory impractical.
Improved logging during init of the connection pool.
We now avoid generating too much log content for timeouts.
Fixed a condition where recovery could lead to out-of-memory errors.
The logging noise in JDBC has been reduced significantly.
Added warning to the log if prepare yields errors.
The new 'propagateJtaTimeoutToXaResource' configuration property for JDBC and JMS now allows you to disable timeouts propagate via XA. For some vendor's XAResoure implementations this timeout seems to give problems and this property can serve as a workaround.
This was for a development team had no influence on the XA settings of the Oracle database (owned by the DBA team). The JTA/XA timeout they used seemed to conflict with the internal Oracle timeout settings, so they got lots of errors on recovery after a restart. This caused their project to look bad.
Since there was no control over their Oracle, this gave them a workaround to (at least) not interfere with transaction timeouts in Oracle. This meant they could avoid getting blamed by the DBAs for setting “bad" timeouts. We have no other record of occurrence, so it looks like this was not a common issue and unlikely something we can improve or change in our product. But we did want to allow users to tune / tweak XA somewhat in similar cases, because different vendors sometimes have different interpretations. Which brings us to the next feature below...
Vendor-specific flags for starting a new XA branch as well as joining/suspending/resuming/ending an existing branch are now supported on the JDBC and JMS connector classes.
The new property 'xaPropertyNamesToHide' allows you to specify what vendor-specific XA properties should be hidden in the log entries. Typically, this would be used for sensitive information like passwords.
Improved handling of class loading to be consistent in OSGi with the rest of the code base.
Fixed JMX to work in OSGi too.
Improved exports in our OSGi bundle - for improved OSGi comfort.
As of this release, we no longer use our proprietary logging configuration mechanism. Instead, we now use your application's logging mechanism/framework by configuring a logger for com.atomikos or nested packages. This also yields better performance because w e no longer log to two destinations (our internal tm.out and other) but rather to one.
Improved poolSize javadoc.
The examples for ExtremeTransactions now contain a working OSGi example.
Prior to this release we relied on the JDK logging API. Due to a built-in limitation of the JDK logging, Tomcat-based tm.out files would often be messed up. This should now be fixed, by allowing you to select a different logging strategy like log4j or logback.
Various tuning interventions on String processing to improve performance here and there.
The fact that the pool is being destroyed should not be a warning but rather an informational log entry. This has now been implemented as such.
