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.
- 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.
- 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.
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
Or check Maven Central (no samples available there)
See our Community Page for how to join us.
Pull latest from repo git pull origin master and try mvn clean install -Popensource.
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):
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-2020, Atomikos - all rights reserved. Visit www.atomikos.com for more...