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
- Your service mesh knows where to send a request. But does it know whether the transaction committed? A network timeout occurs. Your service mesh retries the request. But there is the problem: The original request may already have updated the database. The response simply never made it back. Now the same business operation could execute twice. This is why traffic reliability and transaction consistency are two different challenges. Service meshes help with routing, retries, timeouts, and circuit breaking. But they don't automatically
- Not every business operation can afford to be eventually consistent. Eventual consistency is a perfectly valid architectural choice. Until the operation you are dealing with requires multiple systems to agree on the outcome. Imagine a payment workflow: - A payment is processed. - The application loses the response. - A retry is triggered. - Without proper safeguards, the customer could be charged twice. The problem isn't necessarily the retry. It's that the system doesn't know whether the original operation succeeded. And when
- AI can generate transaction-management code in minutes. Code that compiles. Code that passes tests. Code that coordinates database updates when everything goes according to plan. But writing the code was never the hardest part. The real challenge begins when things go wrong. What happens when a resource is prepared but never receives the final commit decision? How does the system recover after a crash, network failure, or container restart - without losing updates or creating duplicates? These are the problems that decades of
- What happens when a transaction fails halfway through? In distributed systems, failures are inevitable. But lost updates, duplicate operations, and inconsistent data don't have to be. During his conversation with Josh Long, Guy Pardon, founder of Atomikos, gave a live demo of transaction recovery. Because reliable transactions aren't just about what happens when everything works. They are about what happens 'when things go wrong — and how your system recovers.' That's exactly the kind of challenge we focus on at Atomikos:
- Atomikos meets the Bootiful Podcast! What happens when two passionate Java experts get together to talk technology? Our very own Guy Pardon, founder of Atomikos, joined Josh Long on the Bootiful Podcast for a conversation about Java, Spring, and the world of enterprise software. Josh is known for his enthusiasm for all things Spring, and Guy has spent years helping developers solve one of the trickiest challenges in distributed systems: keeping data consistent across services. We're excited to see these two connect! 🎥 Watch
- You added `Transactional`. So your data is safe, right? Not necessarily. In Spring Boot, `Transactional` makes transaction management remarkably convenient. But there is an important distinction: A transaction within one database isn't the same as a distributed transaction across multiple systems. Consider a common scenario: Your application updates a database and publishes a message. The database update succeeds. The message fails. Now what? Adding `Transactional` doesn't automatically make both operations succeed or roll back
- The Outbox Pattern solves one problem. But who takes care of the problems it introduces? Imagine this: An order is successfully saved to the database. But before the corresponding event reaches the message broker, something goes wrong. The order exists. Other services don't know about it. That's the dual-write problem. The Outbox Pattern offers an elegant solution: store the business update and the event in the same database transaction, then publish the event asynchronously. Problem solved? Partly. Now someone needs to make sure:
- Event-driven architecture doesn't mean giving up on strong consistency everywhere. That is an assumption worth questioning. Events are excellent for decoupling services and allowing work to happen asynchronously. And for many operations, eventual consistency is exactly the right trade-off. But consider a common Java operation: 1. Update a database 2. Publish a message The downstream consumer can be asynchronous. But what about the boundary between updating the database and sending the message? If the database commits but the
Related profiles
Something wrong or missing? Send an update. Fixed within 24 hours.