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.

Error: image not found

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

Recovery action log

Available in Atomikos ExtremeTransactions (commercial only).

*Prerequisite: this feature requires DDL to be applied to the LogCloud database before it does anything.* Atomikos never creates or alters tables in your LogCloud database automatically - a DBA must run the following DDL first:

CREATE TABLE RECOVERY_ACTION_LOG (
    OWNING_RECOVERY_DOMAIN_NAME VARCHAR(45) NOT NULL,
    COORDINATOR_ID               VARCHAR(36) NOT NULL,
    XID                          VARCHAR(2000) NOT NULL,
    ACTIVE_JVM_ID                VARCHAR(2000) NOT NULL,
    ACTION                       VARCHAR(20) NOT NULL,
    DECISION_TIME                BIGINT NOT NULL,
    ID                           VARCHAR(36) NOT NULL
);

CREATE TABLE RECOVERY_HEURISTIC_LOG (
    OWNING_RECOVERY_DOMAIN_NAME VARCHAR(45) NOT NULL,
    COORDINATOR_ID               VARCHAR(36) NOT NULL,
    XID                          VARCHAR(2000) NOT NULL,
    ACTIVE_JVM_ID                VARCHAR(2000) NOT NULL,
    OUTCOME                      VARCHAR(20) NOT NULL,
    DECISION_TIME                BIGINT NOT NULL
);

Until both tables exist (with the ID column on RECOVERY_ACTION_LOG - older deployments that already created this table before this feature shipped must add that column), recovery action logging silently stays disabled: nothing is written, and nothing is logged or reported to say why. This is deliberate - the feature only activates once its own schema is present - but it does mean a missing/incomplete DDL run produces no visible error on the write side. See the DB viewer section below for what happens on the read side if the DDL is missing.

When recovery resolves an in-doubt transaction branch against a resource, it either replays the original commit decision or presumes abort, depending on whether a durable commit record was found. In a LogCloud deployment, every such decision is additionally recorded in two dedicated tables in the shared LogCloud database, so that a split between branches of the same transaction can be spotted after the fact:

• RECOVERY_ACTION_LOG — one row per PRESUMED_ABORT or REPLAY_COMMIT decision recovery makes for a coordinator/xid/JVM/action combination. Capped at 3 rows per key (append-only otherwise).
• RECOVERY_HEURISTIC_LOG — one row per heuristic outcome (for example HEUR_ABORTED) reported for a coordinator/xid/JVM combination.

These tables are informational only: they do not participate in recovery decisions, they exist purely so an operator can later reconstruct what happened to a given coordinator.

Retention

Because both tables are append-only, LogCloud runs a daily sweep that removes rows older than a configurable retention window:

com.atomikos.icatch.logcloud_recovery_action_log_retention_days=90

• Default: 90 days.
• Set to 0 or a negative value to disable the sweep entirely (rows accumulate indefinitely).
• A key's rows in RECOVERY_ACTION_LOG and RECOVERY_HEURISTIC_LOG are only removed once both tables' activity for that key is older than the retention window — so a row is never deleted while a still-recent row for the same coordinator/xid/JVM exists in the other table.

LogCloud DB viewer — Recovery actions screen

Available in Atomikos ExtremeTransactions (commercial only).

The LogCloud DB viewer is a small, self-hosted web application (transactions-logcloud-portal) that exposes a read-only view over the LogCloud tables described above. Today it ships with a single screen: Recovery actions.

What it shows

A live, paginated table of every row in RECOVERY_ACTION_LOG, newest first: decision time, coordinator, xid, active JVM id, and the action taken (PRESUMED_ABORT or REPLAY_COMMIT). Use "Load more" to page through older rows, or the search box / action filter chips to narrow down to a specific coordinator, xid, or action type.

Prerequisite: DDL must be applied

The viewer needs the same DDL as the "Recovery action log" section above. If RECOVERY_ACTION_LOG does not exist yet, the Recovery actions screen shows a message in place of the table explaining that recovery action logging is not enabled and linking back to this page for the schema - it does not silently show an empty table, and it does not fail with a raw error either.

Accessing the viewer

The viewer is a Spring Boot application, distributed as a single executable transactions-logcloud-portal-VERSION.jar as part of your Atomikos ExtremeTransactions subscription. Run it, pointing it at the same LogCloud datasource as the rest of your LogCloud-enabled nodes - there is no default, so it fails fast on startup if these are not set:

java -jar transactions-logcloud-portal-VERSION.jar \
  --spring.datasource.url=jdbc:VENDOR://HOST:PORT/DATABASE \
  --spring.datasource.username=USERNAME \
  --spring.datasource.password=PASSWORD \
  --spring.datasource.driver-class-name=VENDOR_JDBC_DRIVER_CLASS

Once started, open it in a browser at the printed port (default 8080, override with --server.port). It has no authentication of its own — put it behind whatever access control your deployment already uses for internal operational tools.

The underlying GET /recovery-actions endpoint returns plain, self-describing JSON, so it can just as easily be queried directly - including by an AI coding agent using ordinary HTTP tooling - without going through the browser UI.

Try it

Try it for yourself by taking our free trial:

Free Trial