Under certain circumstances, closing a connection twice could affect intermediate reuse from the pool. This has now been fixed.
Non-XA participants could not be deserialised from the logs without this extra dependency.
Our write-ahead module contained an obsolete license check that prevented it from working with recent customers who no longer have/need license files in their installation.
Our log utility now also shows statistics on the average byte size of log entries.
The configuration details to allow JMX-level changes of the log level have been added to the spring JMX example and to the wiki documentation.
The LogUtil application now also shows any heuristic messages.
When warnings are not appropriate, commit-level are logged is INFO anyway - to allow diagnosing the details by our support team.
Exceptions are now treated without warnings when possible - as in case 135274 and case 135291 and case 135290.
We now log a warning only if the maxPoolSize equals the default (rather than the minPoolSize).
Avoid useless log warnings and stack traces if there are errors on commit that are not anomalies in the transaction outcome.
During 1-phase commit, some JMS brokers (ActiveMQ and other?) sometimes fail to recognise the Xid being committed. Instead of raising a needless heuristic (hazard) exception, this is now treated as internal timeout/rollback in the resource, and merely yields a RollbackException instead.
This is important when used with Spring's message listener containers because Spring will attempt to commit if there is no message on the queue, leading to a 1-phase commit where this can happen.
To improve the interpretation of the output of our LogUtil, it helps if extra details are shown - so the toString() method now returns output like this:
XAResourceTransaction: 7075626C697368657230303030313030303031:7075626C69736865723131 [IN_DOUBT in resource amq1]
