Overview
Atomikos offers transaction management solutions for distributed systems through its TransactionsEssentials (open source) and ExtremeTransactions (commercial) products. The company enables JEE and lightweight business process management for REST, allowing developers to build self-contained cloud-native applications with transaction support outside traditional application servers.
In the news
- Safe to retry doesn’t mean safe to partially commit. Idempotency is an important tool in distributed systems. It can answer a critical question: “Can I safely repeat this operation?” But consider a business operation that needs to do two things: Update a database Send a message Now imagine: Database update + Message sent - Making the database operation idempotent may make it safer to retry. But it doesn’t change the fact that the business operation has already reached two different outcomes. That is the difference between
- It’s Coding Week, so here is a question worth asking: How much failure-handling code should your application actually contain? When one business operation touches multiple transactional resources, developers can end up writing code for: - retries - duplicate detection - compensation - reconciliation - recovery after failure Sometimes that application logic is exactly what the architecture requires. But sometimes the resources involved can participate in the same transaction. In those cases, transaction coordination can move part
- Applications crash. Containers restart. Processes disappear. But a transaction may already have reached a point where simply running the business operation again isn’t enough. A database may have prepared its changes. A message broker may have prepared its part. Then the application disappears. After restart, the question isn’t just: “Should we retry?” It’s: “What happened to the original transaction?” Transaction recovery exists to answer that question and drive participating resources toward the correct outcome. With Atomikos,
- One business operation. Two resources. 1. Update a database with JDBC 2. Send a message with JMS What happens if step 1 succeeds and step 2 fails? Database update + Message sent - Now the business operation is only partially complete. You can design application logic to detect and repair that inconsistency. Or, when both resources need one atomic outcome, they can participate in the same transaction. That's where Atomikos fits. Atomikos coordinates transactional resources such as JDBC and JMS so related work can reach one outcome:
- A distributed transaction is in progress. The database is prepared. The message broker is prepared. Then the application crashes. What happens when it starts again? Simply retrying the business operation doesn't answer the most important question: What was the state of the original transaction? Transaction recovery needs to determine which resources participated, what state they reached before the crash, and whether the interrupted transaction should be completed or rolled back. That is one of the jobs of a transaction manager.
- Retry is not the same as recovery. Imagine an application crashes halfway through a distributed transaction. When it comes back up, what should happen? A retry asks: “Should I execute the operation again?” Recovery asks a different question: “What had already happened before the crash?” That distinction matters. If multiple transactional resources are involved, some may already have reached a prepared state when the application disappears. Simply repeating the work doesn't tell you what state those resources are in — or how the
- What disappeared when Java moved away from application servers? More than many teams realized. Application servers bundled a lot together: servlet container, deployment model, connection pooling, transaction management, recovery, and more. Modern Java unbundled much of that. Spring Boot, containers and cloud-native architectures gave teams more freedom and lighter deployments. But one problem did not disappear: Transaction coordination. Applications still update databases. They still send messages. They still crash halfway through
- A transaction manager does not prevent failures. It determines what should happen when they do. Imagine one business operation needs to do two things: 1. Update a database 2. Send a message If those two actions are handled independently, one can succeed while the other fails. Database committed + Message not sent - Now the business operation is only half complete. Atomikos coordinates transactional resources such as JDBC and JMS so related updates can participate in the same transaction. That means the application gets one
Related profiles
Something wrong or missing? Send an update. Fixed within 24 hours.