Atomikos TransactionsEssentials: light-weight distributed transactions

Community development "mirror" of atomikos.com/Main/TransactionsEssentials.

New contributors welcome - help us shape transactions for the cloud!

Please star this project to help us grow. Thanks in advance!

• Distributed transaction management for Java - so your Java application gets instant reliability without design efforts in your code.
• Microservices support - so you can have one global transaction spanning several services.
• JEE compatible - so it integrates effortlessly in your Spring or Tomcat configuration.
• Javax and JakartaEE compatible - so you can use the latest greatest ecosystem if you want to.
• Light-weight - so your microservices can use it, too.
• Embeddable in your code - so you can test everything in the IDE and avoid late integration issues at deployment time.
• OSGi support - so you can use OSGi containers also.
• Connection pooling for JDBC and JMS - so you get maximum performance. Pooling can also be disabled per datasource if needed (e.g., for testing, debugging, serverless environments, or third party pooling delegation).
• Built-in support for Hibernate and JPA - so you can use your favorite persistence framework.
• Automatic crash / restart recovery - so your incomplete distributed transactions are cleaned up and your data returns to a consistent state.
• Cloud-native design - so your applications are ready for deployment to your cloud.
• Commercial support available - if you're serious about transactions in your business.

Relevant jars are transformed into jakarta equivalents so we support both Javax and Jakarta.

Since 6.0 we publish both javax and jakarta variants. To keep this working, some core dependencies are marked as provided and we post-process certain jars with the transformer to produce the jakarta classifier. As a result, some modules cannot express a transitive dependency on others (for example, transactions-jdbc cannot depend transitively on transactions-jta) because the runtime dependency must match the chosen classifier.

If you build or run outside an application server, make sure you add the correct variant of these APIs explicitly.

Use the product BOMs to align versions:

• javax BOM: com.atomikos:transactions-essentials
• jakarta BOM: com.atomikos:transactions-essentials-jakarta

Example usage:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.atomikos</groupId>
      <artifactId>transactions-essentials</artifactId>
      <version>${atomikos.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Use the jakarta BOM instead if your runtime is jakarta-based:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.atomikos</groupId>
      <artifactId>transactions-essentials-jakarta</artifactId>
      <version>${atomikos.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

With microservices, the typical monolith ACID transaction becomes split into 2 or more local transactions, one in each microservice. This can quickly lead to inconsistencies - for instance if there are network timeouts or other failures:

Some concrete examples of possible inconsistencies:

• For network timeouts, microservice 1 does not see the difference between a failure/rollback of microservice 2 and a commit at microservice 2. The global system state (and consistency) is undefined.
• For retries (when microservice 1 calls microservice 2 a number of times until it does succeed) we depend on microservice 2 offering a correct implementation of an idempotent consumer. This is hard and error-prone.
• Also for retries, microservice 1 has to remember that it needs to retry at microservice 2. This adds technical complexity to an otherwise simple scenario.
• For failures when invoking microservice 2 there is no easy alternative but to retry (due to the above). This means you can't have microservice 1 forget about microservice 2 and try an equivalent "competing" implementation. Why? Because it just might be that the invocation of microservice 2 did actually commit.

We allow 1 global transaction, even across separate microservices and you don't have to code anything for that. In the example shown, a failed call means rollback at microservice 2, and if you want then you can safely try an alternative microservice instead (even within the same global transaction).

Working samples are included in our official download. This enables safer retries (if you do want to retry - that is your choice) plus the notion of a global commit.

For more information on how to fine-tune microservice transactions: check out our online course.

See Getting Started for general documentation.

See documentation at www.atomikos.com/Documentation

Register and download from www.atomikos.com

Register and download from www.atomikos.com and get documentation plus working sample applications

Or check Maven Central (without the samples or documentation)

Atomikos is a good fit when you need distributed transaction coordination across multiple resources. Use it when:

• You need atomicity across multiple transactional resources (e.g., DB + JMS)
• You need JTA/XA semantics in a Java stack
• You must coordinate commit/rollback across multiple databases or brokers
• You need crash-safe recovery of in-flight distributed transactions
• You are tired of implementing Saga logic and want automatic distributed transactions in a microservice architecture
• You want to drop your application server but keep distributed transactions
• You want exactly-once messaging without duplicates, retries, or lost messages
• You want to eliminate brittle eventual consistency and idempotent consumer patterns
• Your transactions involve valuable content that has a high cost if delivered twice or if lost (payments, insurance claims, expensive back-end commands)

If you only use a single database and don’t need cross-resource atomicity, a local transaction manager is usually sufficient.

See our Community Page for how to join us.

Pull latest from repo git pull origin master and try mvn clean install -Popensource.

AI Agent sessions (like Codex or Claude Code) must read USING_AGENTS.md before making changes.

The fastest way to contribute is by starring this project. Thank you :-)

See our contributor guidelines for inspiration and guidance.

See our code of conduct for details and how to report violations.

This GitHub project is merged with - and updated regularly from - our internal development repository to work towards our next open source release (note: stable maintenance releases and our commercial power features are managed outside GitHub).

IMPORTANT: we (Atomikos) don't develop on GitHub ourselves (yet) so you won't see a lot of our commits here - only refreshes when we merge + push to GitHub. That is because at least initially, the sole purpose of this project is to allow interested GitHub community members to fork and contribute useful features to what we have.

Activities here are probably higher when:

• we prepare a new community release (milestone), and
• the 3 months of stabilization period after that (during which we publish lots of bug fixes)
• (check the milestones page with due dates to get an impression...)

After that, we are busy upgrading our customers and on-boarding new customers so you will see less activity here. That's because most customer work is done in our private repositories.

You know how it goes, one always forgets to mention someone - but the following fine people have all delivered memorable technical contributions to this project in one way or another.

So: thank you! (and apologies to the superstars not mentioned here):

• @pascalleclercq
• @tkrah
• @dpocock
• @lorban
• @dandiep
• @gregw
• @janbartel
• @Fungrim

See our license policy page.

Do you think something's missing on this page? Please open an issue to let us know!

Copyright (c) 2000-2023, Atomikos - all rights reserved. Visit www.atomikos.com for more...