ExtremeTransactions 6.0.110

Release notes for 6.0.110

Feature207056

Improved core classes for concurrency / threading

You can now benefit from reduced synchronisation overhead thanks to concurrent maps usage in our core classes.

Technical details

We've added 2 new implementation classes: DefaultTransactionService and DefaultCompositeTransactionManager. These comply with our newly documented Concurrency Model for correctness in multi-threaded applications. We now also use concurrent maps thanks to this this contribution on github.

The new DefaultTransactionService also has better / simpler shutdown logic for the transaction service.

Changes impacting client API

This feature can (for now) be toggled with a flag in jta.properties:

   om.atomikos.icatch.feature.207056 = true 

This is enabled by default because we are confident it works better than before. If you experience problems after upgrading, set this to false…

Feature203242

Retry file lock on startup

You can now shift Kubernetes pods by starting a new pod while the old one is still terminating.

Technical details

In Kubernetes environments pods might be terminated and shifted to other nodes. Because of this the configured log path might be in use if the old pod is about to terminate and the new one is starting up. To be able to use the same LogFileLock we now offer retry attempts for the new pod which is trying to acquire the lock.

Changes impacting client API

None, we have reasonable default configuration properties in JTA Properties, prefixed with com.atomikos.icatch.log_lock_acquisition.

Feature201646

Spring Boot 2 starter: use the jta and jms versions of Spring Boot's POM in the starter project

You can now use the same JTA and JMS dependency versions of Spring Boot's rather than the ones we specify.

Technical details

For Spring Boot 2 we used to specify a particular version for each of JTA and JMS. This would override the versions that Spring Boot prefers. We no longer do this.

Changes impacting client API

None.

Feature207758

Examples for Hibernate 7

You can now check the examples for Hibernate 7.

Technical details

We've added working samples for Hibernate 7.

Bug202474

Refine exception message when creating a JDBC statement fails

Severity:	3
Affected version(s):	6.O.x, 5.0.x

Description

You can now expect more accurate exception messages when creating a JDBC statement fails

Technical details

We used to have one generic exception message when a statement could not be created, each time suggesting a timeout of the transaction. This was confusing if the real reason was, for instance, the transaction having been marked for rollback only.

The code has been refined live this:

   TxState state = ct.getState();
   if (state == TxState.ACTIVE) {
      ct.registerSynchronization(new JdbcRequeueSynchronization(this, ct));
   } else if (state == TxState.MARKED_ABORT){
      AtomikosSQLException.throwAtomikosSQLException("The transaction has been set to rollback-only");
   } else {
      AtomikosSQLException.throwAtomikosSQLException("The transaction has timed out - try increasing the timeout if needed");
   }

Changes impacting client API

None.

Bug202466

Interposed synchronisation instances not called on regular rollback

Severity:	3
Affected version(s):	6.O.x

Description

Interposed synchronisation instances are now called on regular rollback also.

Technical details

See this github issue for details.

Changes impacting client API

None.

Bug208965

Bug in borrowing connection: make waiting for available connections fair(er)

Severity:	3
Affected version(s):	6.0.x

Description

Getting a new connection is now more efficient.

Technical details

Details are explained in this github issue.

Changes impacting client API

None.

Bug209260

Expose AtomikosSQLException in public package (for OSGi)

Severity:	4
Affected version(s):	5.O.x, 6.0.x

Description

The class AtomikosSQLException was not exposed as public in OSGi.

Technical details

The class AtomikosSQLException was not exposed as public in OSGi because it was in an "internal" package. This class has been moved to a public package instead, so it can be used with OSGi.

Changes impacting client API

You have to change the imports when your code references this exception.

Bug207055

Bug in timeout/rollback of local sub transaction followed by commit of its parent

Severity:	3
Affected version(s):	5.0.x, 6.0.x and prior (decorated) releases

Description

Timeout / rollback of a subtransaction no longer appears as a commit to the parent transaction.

Technical details

Timeout with subsequent rollback of a subtransaction would interfere with a later commit of the parent transaction: the state handler for the subtransaction would erroneously reply with READONLY upon 2PC prepare. This would make it seem to the parent transaction as though commit may proceed. We've fixed this by checking for timeout upon prepare of a subtransaction. Most people are not using subtransaction functionality, but those who do will benefit from this fix.

Changes impacting client API

None.

Bug207046

Improve 2-phase commit for imported transaction to align with the new concurrency model

Severity:	3
Affected version(s):	5.0.x, 6.0.x and prior (decorated) releases

Description

We improved the way imported transactions are handled in the case of network timeouts - so it aligns with our concurrency model.

Technical details

This release includes an improved concurrency implementation (as per feature 207056 above), along with a newly documented concurrency model as shown in Concurrency Model. We've updated the handling of imported transactions to be consistent with the new concurrency model. In particular, the following scenario has been improved:

• A remote client propagates a transaction to your service, possibly on a number of times on different invocations.
• The last invocation "I" appears to "fail" at the remote client due to a network timeout, but the invocation as actually still active at your service.
• The remote client decides to terminate the transaction by either commit (which is possible if "I" is considered optional) or rollback.
• Depending on the complexity of the remote transaction, this will lead to either of an incoming "PC": prepare, rollback or 1-phase commit call in your service.
• The classical way we dealt with this was instant rollback triggered by the incoming "2PC", but this violates our new concurrency model.
• So we now let the pending active invocation do the rollback instead - in line with the concurrency model.

Changes impacting client API

None.

Bug207146

High memory consumption due to adding JDBC statements multiple times to the same list

Severity:	3
Affected version(s):	6.0.x

Description

Creating many JDBC statements no longer leads to high memory consumption.

Technical details

For technical reasons we keep a "cached" collection of JDBC statements. Due to a bug, such statements were added multiple times to a list. We fixed this by:

• Changing the list to a Set, and
• Removing the lines of code that added statements more than once.

Changes impacting client API

None.

Bug209259

Improve thread-safety of CheckedExportingTransactionManager

Severity:	3
Affected version(s):	5.0.x, 6.0.x

Description

We improved the tread-safety of CheckedExportingTransactionManager in module transactions-remoting.

Technical details

We changed the use of a HashMap to a ConcurrentHashMap for pending request synchronisation instances.

Changes impacting client API

None.

Bug202750

ConnectionPool: endless loop on interrupt during waitForConnection

Severity:	3
Affected version(s):	4.0.x, 5.0.x, 6.0.x

Description

Interruptions during Spring Boot shutdown are now handled better by the connection pool.

Technical details

Full details as disclosed in the original report:

We experienced a somewhat strange behaviour with Atomikos in a situation, where our application (Spring Boot) is shutting down while some threads are waiting for a connection. In this shutdown-situation, Spring Boot sends an 'interupt' to all running threads. The Atomikos ConnectionPool method 'waitForAtLeastOneAvailableConnection()' handles this InterruptedException by invoking the InteruptedExceptionHelper. This in turn logs the exception and re-interrupts the thread. This is the correct pattern to interrupt possible further waits in the call stack.

But the method does not leave the while-loop. This causes a loop for the remaining borrowConnectionTimeout, leading to a very large amount of exception logs.

Changes impacting client API

None.

Bug210111

Missing jar in eval download: transactions-tomcat-jakarta

Severity:	4
Affected version(s):	6.0.x

Description

You can now use the Tomcat Jakarta functionality in the free trial download.

Technical details

The relevant jar file for this was missing from the evaluation zip file. It has now been added.

Issue202334

Modify Tomcat examples to use Docker

Severity:	4
Affected version(s):	6.0.110

Description

The Tomcat examples have been modified to user Docker, but this does not work on all platforms yet.

Technical details

The Docker image generated to run the Tomcat examples contains a Java JDK that is not binary compatible with all platforms yet.

About Severity

The severity levels we use are defined in our support terms and conditions.