TransactionsEssentials 5.0

Release notes for the 5.0 release

Remoting for transactions across microservices, new improved recovery, simplified design and better JDBC support.

Upgrading from 4.0

Upgrading should be easy, and in case you have issues then do the following to get backward compatibility:

• Set localTransactionMode=true on your JDBC datasource(s)
• In jta.properties, set com.atomikos.icatch.throw_on_heuristic=true

IMPORTANT: since the log file format has changed, make sure to do a clean shutdown first so you can safely remove the existing transaction logs.

Remoting support for microservices

Ever heard of ACID transactions being an anti-pattern? Mostly this is because people don't know how to do it. This has now changed!

Check out examples-jta-rest-jaxrs to see how easy it is to commit or rollback across multiple services.

Simple TransactionTemplate

Maybe you use Spring, maybe you don't. Either way, you can now use our new com.atomikos.icatch.jta.template.TransactionTemplate to demarcate transactions with the known semantics (REQUIRED, REQUIRES_NEW, MANDATORY, NEVER, SUPPORTS, NOT_SUPPORTED and NESTED). Lambda's are supported, too.

No throwing of heuristic exceptions

We no longer throw on heuristic exceptions - because heuristics are an operations issue, not a developer issue. However, if your code depends on heuristics then you can switch on the old behaviour in jta.properties like this:

com.atomikos.icatch.throw_on_heuristic=true

New and simplified recovery

We've made recovery even simpler, so it works better and faster - even in the cloud: your application's transaction processing now merely inserts log records, and all other processing and cleanup is done in the background (by the recovery subsystem). This achieves the ultimate and complete separation of concerns between OLTP logic and recovery logic. The logs are also more compact because we no longer store individual XIDs.

Automatic archiving of heuristic problems

Heuristic problem cases are now mostly archived automatically so they will no longer "pollute" the log files. Your application can capture details with our event API - so you can log whatever you need to deal with such problems.

The LogAdministrator interface had been removed from our API because it became obsolete now that we deal with heuristics automatically.

Filter out "duplicate" resources for recovery

With the 4.0 recovery, multiple connection factories or datasource to the same backend would lead to many recovery calls. Now we filter out duplicates - so each backed is only recovered once during each recovery scan.

Easy proxy creation

We've added support for easy and elegant dynamic proxy creation. This means that we can have better proxies (typically needed for JTA enlist/delist). Our JDBC and JMS modules have been refactored to leverage this new design.

API simplification

We've simplified our (internal) API based on insights we've collected over the years. Most notably, our API no longer requires Serializable support and the transaction import/export mechanism has also been cleaned up to allow for elegant HTTP / microservice transactions.

Improved JDBC Non-XA support

The classes for the non-XA datasource have been improved for more safety and flexibility:

• Subtransactions are now supported
• Multiple read-only instances can be used in the same transaction
• Non-read-only instances will fail if used in two-phase commit

Here are some relevant GitHub issues:

• https://github.com/atomikos/transactions-essentials/issues/83
• https://github.com/atomikos/transactions-essentials/issues/85

Also, the class AtomikosNonXADataSourceBean has now been moved into package com.atomikos.jdbc (alongside our AtomikosDataSourceBean).

Safer JDBC design

We used to allow a mix of local transactions and JTA transactions (depending on whether a JTA transaction existed or not). As of this release, only JTA transactions are allowed for JDBC - unless explicitly overridden by setting "localTransactionMode=true" on any of our datasources.

JDBC statement housekeeping

We no longer keep JDBC statements after they are closed, which means less memory consumption.

JmsSenderTemplateCallback is a functional interface

For the lambda lovers: you can now do these with the JmsSenderTemplateCallback.

Example with Hibernate 5

We've included a working sample with hibernate 5

Example with Spring 5.1

We've upgraded the Spring example to use a recent version of Spring.

Removed JUL logger from examples

Some people thought we had a JUL logger dependency in the examples. This has now been removed.

Free Download