What is it?

Available as of ExtremeTransactions 5.0, the LogCloud is our answer to the needs of transaction processing projects that need to move into the cloud. Cloud applications often cannot take for granted that there will be persistent storage available. Cloud applications also need self-healing infrastructure.

The LogCloud is a cloud-enabled transaction logging and recovery service so your cloud application nodes themselves do not need any persistent storage. All transaction logging and recovery is taken care of by the LogCloud, so application nodes can come and go without affecting transaction recovery.

This enables truly elastic OLTP in the cloud, with the recovery service in the background - taking care of cleaning up any pending transactions.

Self-healing characteristics eliminate almost every need for administration. It was never easier to do distributed transactions!

How does it work?

A typical LogCloud deployment is shown in the figure below. Note that LogCloud is not a single actor but rather an emergent characteristic of a particular configuration based on a shared DBMS for transaction logs.

Let's discuss the important actors and how they collaborate:

Shared LogCloud DBMS

One or more transactional application nodes use the LogCloud DBMS for maintaining (and recovering) their transaction logs, because in cloud environments application-level disk access may not be available.

Transactional Application Node(s)

Embedded inside each application node is a recovery component that connects to the shared DBMS to access the transaction logs. A master election process ensures that this works without overloading everything: only one active node will do the recovery. As long as at least one node of your application cluster is online, recovery will work.

XA Resource Backend(s)

The backend resources used by the application nodes are the ones that need to be recovered by the LogCloud. So it's logical that the LogCloud needs access to those. This is trivially ensured by the recovery running inside each application node: it can access all the resource configurations that the application uses.

Configuring the LogCloud

Choose your deployment architecture

If your application is a "clustered deployment" (identical applications / microservices deployed a number of times) and your transactions span XA backends (i.e., not different microservices) then the simplest option is to use the same physical database for both application data and LogCloud data. All application instances should use the same value for the property com.atomikos.icatch.tm_unique_name.

However, if you are considering transactions that span multiple microservices (so if commit and rollback span microservices, not just XA backends) then you should consider one dedicated database for all LogCloud data of all your microservices. That will make distributed recovery more efficient. In this case, each microservice can be clustered (all equivalent nodes of a microservice must have the same value for com.atomikos.icatch.tm_unique_name) but different microservices must have a different value for com.atomikos.icatch.tm_unique_name.

Example with Spring Boot

For a working example with Spring Boot, check here: https://github.com/atomikos/spring-boot-sample-jta-atomikos-logcloud.

Most of the instructions below are done automatically if you run the example (also check its configuration files).

Create a system account for the LogCloud database

1. Choose your DBMS (it needs to support JDBC)
2. Create a server instance
3. Create a user account for recovery.

Make sure to setup this user account on your DBMS server first! The account also needs creation rights for tables and indexes (unless you want to setup the tables yourself first - not recommended).

Initialize the DB schema and tables

• Create the schema
• Initialize the tables with this this script

Note: this is done automatically in the Spring Boot example (via Spring Boot startup config files).

Configure JDBC access for the LogCloud

• Create an instance of com.atomikos.jdbc.AtomikosNonXADataSourceBean with uniqueResourceName=logCloudDS
• Make sure to set the property ignoreJtaTransactions=true
• Set the maxPoolSize (the value can be slightly lower than your regular pool because connections are used only very briefly).
• Initialise it before starting the transaction core

Tuning the LogCloud configuration

Configuring recovery is done via SQL updates in the table "LOG_CLOUD_STARTUP_CONFIG" of the DBMS you selected:

• You SHOULD update the property value of com.atomikos.icatch.tm_unique_name to be unique for this installation, or recovery will interfere among different LogClouds!
• Recovery will terminate pending transactions only after com.atomikos.icatch.max_timeout milliseconds, so you should set this parameter as low as acceptable to avoid pending locks in resources.

Configuring the application nodes

Each application node must be configured to log to the LogCloud instance, by doing all of the following:

• adding the transactions-logcloud jar to the application's classpath
• setting com.atomikos.icatch.tm_unique_name to the same value of the (shared) LogCloud instance's com.atomikos.icatch.tm_unique_name value (in table "LOG_CLOUD_STARTUP_CONFIG")
• making sure that the application's com.atomikos.icatch.max_timeout setting does not exceed the same setting in the LogCloud instance

Configuring the backend resources

The LogCloud automatically recovers all application resources configured for XA.

Beware when you delete a resource from your application's config: you should only do so if you are sure that there are no pending (prepared) XIDs in the resource. The easiest way of ensuring this is by letting each node do a clean shutdown.

Configuring remoting (HTTP) recovery

If you use transactions-remoting (transactions over REST) then you must also add the transactions-remoting-recovery jar to your classpath. This will enable HTTP recovery.

Supported XA backends

The recovery service needs the drivers to connect to each XA backend. By default, the recovery service has the following drivers in its classpath:

• PostgreSQL
• MySQL
• ActiveMQ
• SolaceMQ

We reuse the driver versions from Spring Boot - so the concrete version will depend on what Spring Boot version used.

Note: in principle, any JDBC datasource can be used (including Oracle).

Try it

Try it for yourself by taking our free trial:

Free Trial