What is it?

Available as of ExtremeTransactions 4.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.

The LogCloud is a dedicated 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.

How does it work?

A typical LogCloud deployment is shown in the figure below:

Screenshot 2017-10-22 15.31.35.png

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

Transactional Application Node(s)

One or more transactional application nodes use the LogCloud for maintaining (and recovering) their transaction logs, because in cloud environments application-level disk access may not be available. These application nodes could either be mirrored application deployments in a cluster, or a set of collaborating transactional REST microservices. In the former case each application node probably has the same configuration, in the latter case it concerns different microservice application nodes each with their own configuration.

LogCloud Service

A dedicated node hosts the LogCloud for transaction logging and recovery purposes. In order to work correctly, this service needs disk access (for log storage) and access to the same XA resources that are used by the application nodes.

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. In the config section below we'll clarify how this access is achieved.

LogCloud recovery domain

All of the above concerns one recovery domain - i.e. the set of transactions and resources that need recovery by the same LogCloud. A transaction belongs to a recovery domain if it is started by an application node that uses the LogCloud instance in that domain. By design, XA transactions have to stay within the same recovery domain, meaning that for each application node the following holds:

• all the transactions it starts are within the same recovery domain
• all resources it accesses must be made accessible to the LogCloud instance of that domain
• all other application nodes that are called within a transaction must also belong to the same recovery domain

How do I configure it?

Configuring the application nodes

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

• setting com.atomikos.logcloud.rmi.url to the RMI URL of the LogCloud service (in the application's jta.properties file),
• setting com.atomikos.icatch.tm_unique_name to the same value of the (shared) LogCloud instance's com.atomikos.icatch.tm_unique_name value
• adding the logcloud-client jar to the application's classpath
• making sure that the application's com.atomikos.icatch.max_timeout setting does not exceed the same setting in the LogCloud instance

Configuring the LogCloud instance

Determine the folder on the host where you will start the LogCloud. Then, make sure to do the following:

• create a subfolder lib/
• add all JDBC and JMS drivers to the lib/ folder so LogCloud can connect to the resources
• create a jta.properties file for the LogCloud (and place it in the lib/ folder so it's found by the process)
• start the service (see the examples-logcloud-nanny sample project or ask your support contact)

As application nodes start and initialise their connection pools, these connections will be mirrored on the LogCloud. So there is no immediate need to configure the user/password for recovery: this will be sent over by the application nodes.

Configuring the backend resources

The backend resources need to be configured for XA transactions, but that is outside the scope of the LogCloud documentation (since that has to be done for all XA transaction uses).