ExtremeTransactions 5.0.99

Release notes for 5.0.99

Release notes for 5.0.99

Bug180060

Clarify warning message on failing prepare

Severity

3

Affected versions

4.0.x, 5.0.x

Description

You can now easily see whether prepare fails due to either a timeout, or due to a resource-internal issue.

Technical details

The warning message in the log files now distinguishes between a transaction timeout (where you can increase your timeout settings) and other reasons that don't require changes in timeout settings.

Changes impacting client API

None.

Bug189063

Reduce lock contention on the pooled connection

Severity

4

Affected versions

5.0.x

Description

Concurrent connection pool requests now have less waiting on synchronised code for connections that are already in use.

Technical details

The method AtomikosConnectionProxy.isAvailable() has a synchronised block of code that would be entered every time, for every concurrent request and for every connection. Now, when the connection is already in use we avoid entering the locked section of code.

This leads to lower contention in high load environments.

Changes impacting client API

None.

Bug189264

Also stop a transaction's background timer thread when delegating work to recovery

Severity

2

Affected versions

5.0.x

Description

When problematic transaction commits are given up and delegate to recovery, we now also stop the transaction's background timer thread.

Technical details

Before this change, problematic commits keep on retrying in the transaction's background thread. This is generally fine, but at some time the transaction manager gives up and delegates to the background recovery process. However, the transaction's background timer thread would stay active in that case. This has now been fixed.

Changes impacting client API

None.

Bug189811

Clarify warning if JMS pooled connection cannot be validated or closed

Severity

3

Affected versions

5.0.x

Description

Exceptions when either testing or destroying a connection in the pool will now clarify that the connection will be replaced with a new connection, so you don't have to worry about having to do anything special.

Technical details

Before this change, exceptions during testing and/or destroying a pooled connection would have a vague message. With this change, the message now clarifies that the connection will be replaced with a new one. This means your operations team does not have to wonder what to do.

Changes impacting client API

None.

Bug189263

Long connection pool wait times when using AtomikosNonXADataSourceBean outside a JTA transaction

Severity

3

Affected versions

5.0.x

Description

Instances of com.atomikos.jdbc.AtomikosNonXADataSourceBean now notify waiting getConnection() requests when a connection in use without a JTA transaction is closed (and becomes eligible for reuse in the pool). This means you will see less frequent waits for borrowConnectionTimeout, so you should see shorter request processing delays.

Technical details

The class com.atomikos.jdbc.internal.JtaUnawareThreadLocalConnection proxy was not firing the required event to notify waiting threads when a thread returned a connection to the connection pool. This in opposition to class com.atomikos.jdbc.internal.JtaAwareThreadLocalConnection that WAS actually firing this event. Due to this, when using JtaUnawareThreadLocalConnection the waiting threads would exhaust the maximum borrow timeout instead of trying to lease connection when notified. Client would notice that awaiting threads always reach the configured borrow timeout regardless another thread returned a usable connection to the pool.

Changes impacting client API

None.

Bug189156

BatchingMessageListenerContainer should report which connectionFactory is set

Severity

4

Affected versions

5.0.x

Description

Instances of com.atomikos.spring.BatchingMessageListenerContainer require an instance of com.atomikos.jms.AtomikosConnectionFactoryBean. If you make a mistake in your wiring then you can now see what (other) connection factory class you are trying to set.

Technical details

Before, calling com.atomikos.spring.BatchingMessageListenerContainer.setConnectionFactory(connectionFactory) with a wrong argument would merely throw an IllegalArgumentException. We now added the actual class name of the argument to the exception's message, so debugging your configuration becomes easier.

Changes impacting client API

None.

Bug189273

Heuristic state handlers: avoid endless commit retry

Severity

3

Affected versions

5.0.x

Description

Heuristic transaction states in your application no longer lead to infinite retries in the background.

Technical details

Even with com.atomikos.icatch.oltp_max_retries=0, the classes HeurHazardStateHandler and HeurHazardStateHandler would lead to endless retries in the background. This was due to the fact that the dispose method in the state handler logic would not delegate to the underlying CoordinatorImp instance, so the timer thread would stay active even after things were left for the recovery process in the background. The timer thread would trigger the retry mechanism.

Changes impacting client API

None.

Bug188918

XaResourceTransaction: don't log ERROR when xaresource is null

Severity

2

Affected versions

5.0.x, 4.0.x

Description

We no longer log an error message but rather just a warning when XaResourceTransaction.commit detects that there is no XAResource to use.

Technical details

Without this fix, you could get into situations like this (which then got logged a LOT due to issue 189273 above):

19/11/2020 15:20:43.467 [Atomikos:3321] ERROR com.atomikos.datasource.xa.XAResourceTransaction - XAResourceTransaction: 31302E3235342E3134362E3131302E746D313539353531353037383735393139373038:31302E3235342E3134362E3131302E746D373030333533: no XAResource to commit?

19/11/2020 15:20:43.467 [Atomikos:3321] ERROR com.atomikos.icatch.imp.CommitMessage - Unexpected error in commit
com.atomikos.icatch.HeurHazardException: XAResourceTransaction: 31302E3235342E3134362E3131302E746D313539353531353037383735393139373038:31302E3235342E3134362E3131302E746D373030333533: no XAResource to commit?
        at com.atomikos.datasource.xa.XAResourceTransaction.commit(XAResourceTransaction.java:529)
        at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:52)
        at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:23)
        at com.atomikos.icatch.imp.PropagationMessage.submit(PropagationMessage.java:67)
        at com.atomikos.icatch.imp.Propagator$PropagatorThread.run(Propagator.java:63)
        at com.atomikos.icatch.imp.Propagator.submitPropagationMessage(Propagator.java:42)
        at com.atomikos.icatch.imp.HeurHazardStateHandler.onTimeout(HeurHazardStateHandler.java:71)
        at com.atomikos.icatch.imp.CoordinatorImp.alarm(CoordinatorImp.java:650)
        at com.atomikos.timing.PooledAlarmTimer.notifyListeners(PooledAlarmTimer.java:95)
        at com.atomikos.timing.PooledAlarmTimer.run(PooledAlarmTimer.java:82)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
19/11/2020 15:20:53.468 [Atomikos:3321] ERROR com.atomikos.datasource.xa.XAResourceTransaction - XAResourceTransaction: 31302E3235342E3134362E3131302E746D313539353531353037383735393139373038:31302E3235342E3134362E3131302E746D373030333533: no XAResource to commit?

We have no report of how the system got into this state, but this can happen on rare occasions when the original connection breaks and a refresh cannot be done.

This is now a warning (since recovery will deal with it in the background) and thanks to the fix for 189273 it will no longer repeat endlessly.

Changes impacting client API

None.

Bug188763

EventPublisher: remove confusing warning if no listeners registered

Severity

4

Affected versions

5.0.x

Description

We no longer log a warning if a heuristic event happens and no event listeners were registered.

Technical details

Previously, when a heuristic transaction happened then the event would get logged as a warning in a place where it was out of context. This was very confusing, even for our team. We considered this logging to be obsolete, since the absence of any event listener signals that the application does not care in the first place.

With this in mind, the warning has been removed. Our monitoring extensions should be used for awareness of such events.

Changes impacting client API

None.

Feature185294

Add gRPC remoting support

You could already make transactions span http remoting calls. With this change, you can now also make transactions span gRPC calls.

Technical details

You can now ship transaction propagation headers along with gRPC calls, so your transaction commit / rollback scope can span gRPC distributed applications.

Changes impacting client API

The module transactions-remoting now has added interceptor for gRPC:

com.atomikos.remoting.grpc.TransactionAwareClientInterceptor and com.atomikos.remoting.grpc.TransactionAwareServerInterceptor

Available to customers only. Want to become a customer?

Send me a quote

I have read and accept the privacy policy.

Message: Please send me a quote for ExtremeTransactions5dot0dot99 Date: 28 Feb 2026 - 01:42 Email: !!address!! Remote-Host: 216.73.216.220