How to build transactional microservice ecosystems with Atomikos: if you want to split-up your monolith then this is how you take care of the integrity of your databases…

The problem

So you're splitting up that monolith into smaller scoped microservices. Then you suddenly realise that what used to be one transaction is now split across multiple processes. It's not easy to make multiple updates across multiple processes and guarantee consistent commit or rollback in case of failures. So what can you do?

The solution

Based on popular demand, we at Atomikos have come up with a solution to manage distributed transactions across separate REST microservices. You can now have atomic, consistent commit or rollback spanning multiple microservice processes.

The client application itself uses an instance of TransactionsEssentials and can use / export its transactions to the external REST services. This means that starting and committing a transaction now happen inside the client's application, and commit includes any external REST services' work.

JAX-RS interceptors

Extending the transaction scope across microservice calls is done via JAX-RS "filters" that intercept incoming and outgoing requests and responses, adding / extracting the necessary information to / from the HTTP headers of the request. Here's how to configure this in your code:

Client-side interceptors

   import com.atomikos.remoting.jaxrs.TransactionAwareRestClientFilter;

   javax.ws.rs.client.Client paymentClient = ClientBuilder.newClient();
   paymentClient.register(TransactionAwareRestClientFilter.class);

The client interceptor automatically detects any active Atomikos transaction in the client JVM and propagates it in the outgoing calls via HTTP headers - so the server on the other end can extract and join that transaction. It also extracts any URLs from the response headers for committing the work of the other end as part of the active transaction.

Server-side interceptors

   import com.atomikos.remoting.jaxrs.TransactionAwareRestContainerFilter;
   import com.atomikos.remoting.twopc.AtomikosRestPort;

   JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean(); //we used CXF for our demo
   sf.setProvider(new TransactionAwareRestContainerFilter());
   sf.setResourceProvider(new SingletonResourceProvider(new AtomikosRestPort()));

The server interceptor detects any transaction propagation in the incoming calls - so it can join that transaction. It also adds HTTP headers to the response, containing a URL to commit its work as part of the transaction of the caller. The AtomikosRestPort listens on the URL and awaits commit requests.

Spring REST interceptors

We have similar interceptors for Spring REST, if you prefer that framework over JAX-RS.

Spring Http Invoker interceptors

The Spring HTTP remoting technology is also supported.

Benefits

Some of the benefits of this technology include:

• Consistent commit or rollback is now possible across different microservices.
• If you call a service and get no response (or an exception) then you know it has not committed anything.
• If you refactor your architecture towards microservices then you don't have to worry so much about consistency.

Try for yourself

This post describes real, working examples of our code base. Download the free open source edition here:

Free Download

Are you serious about REST transactions? Apply here for a free trial of our commercial edition!

Trusted By