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

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).

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.

If you don't use Spring Boot

The application needs to find the LogCloud DBMS. If your application does not use Spring Boot, you can configure access to the database as follows. Note that you still need to do all the steps outlined above.

Initialize the DB schema and tables

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

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

IMPORTANT LIMITATION

We currently don't support cases where multiple clusters share the same logging database. More precisely: we assume that the logging database tables are used by "equivalent" application nodes containing all the JDBC and JMS XA connectors for doing recovery. That way, each node can replace any other node with the master election process and recovery will work fine.

In a future release we may support more advanced configurations, but for now this means that each clustered "application" or "project" will probably require its own database schema and tables, shared among all the nodes of its cluster only.

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.

Try it

Try it for yourself by taking our free trial:

Free Trial