XA transactions for microservices and the cloud
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 newcom.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.
High-performance JMS batch processing
In module transactions-spring we have added com.atomikos.spring.BatchingMessageListenerContainer. This is an extension of Spring's DefaultMessageListenerContainer that adds batched processing of multiple JMS messages. In all our tests this has significantly improved performance. This is a nice example where XA can actually make things faster instead of slower…Spring Boot 2
Using Spring Boot (2)? No problem, we support that!
Monitoring (operations) portal
We've added lots of interesting core events to be monitored, and a monitoring module to log these events - so you can use your favourite log analysis tools to monitor your distributed transactions. The transaction ID serves as the correlation ID.
Enhanced support for AllegroGraph with JTA
The AllegroGraph graph/NoSQL database system supports XA but not easy JTA enlistment - leaving it to your application to enlist low-level XAResource instances with the JTA transaction. We've added support for this, so you don't have to bother any more: you can now use AllegroGraph with the same level of comfort and ease as you can do regular JDBC or JMS with transactions.
See Configuring AllegroGraph for JTA/XA with Atomikos for details.Enhanced support for Hazelcast with JTA
Like AllegroGraph, Hazelcast does not support JTA/XA at a high level (so you end up doing XA operations yourself). This has been improved: we now do this for you, behind the scenes.
See Configuring Hazelcast for JTA/XA with Atomikos for details.LogCloud with DBMS storage
We've made the LogCloud better, based on feedback from users of our previous 4.0 release. Logging is now done directly in the DBMS which simplifies a lot of things for you.
For the full details, see LogCloud Documentation.Removed: RMI transactions
Nobody uses RMI any more, so we removed our RMI transactions module. For transactions that span microservices: try REST/HTTP instead.
Removed JmxTransactionManagerBean
The MBean com.atomikos.jmx.transactions.JmxTransactionManagerBean has been removed since the new recovery has replaced its functionality by event logging.Ask your support representative for details on how to configure event logging / monitoring.
Merged transactions-jmx-jta into transactions-jmx
These modules have now been merged into one module / jar.
JMX: show last reap time
The JMX controls for our datasource / connection factory now also show the last reap time.