com.atomikos.icatch.feature.207056=true
| Severity: | 4 |
|---|---|
| Affected version(s): | 5.0.x, 6.0.x |
| Severity: | 2 |
|---|---|
| Affected version(s): | 6.0.x |
| Severity: | 3 |
|---|---|
| Affected version(s): | 6.0.x |
<dependency>
<groupId>com.atomikos</groupId>
<artifactId>transactions-spring-boot4-starter</artifactId>
<version>...</version>
</dependency>
<dependency>
<groupId>com.atomikos</groupId>
<artifactId>transactions-spring-boot3.4-starter</artifactId>
<version>...</version>
</dependency>
| Severity: | 4 |
|---|---|
| Affected version(s): | 6.0.x |
| Severity: | 4 |
|---|---|
| Affected version(s): | 6.0.x |
| Severity: | 4 |
|---|---|
| Affected version(s): | 6.0.x |
| Severity: | 4 |
|---|---|
| Affected version(s): | 6.0.x |
| Severity: | 4 |
|---|---|
| Affected version(s): | 6.0.x |
| Severity: | 4 |
|---|---|
| Affected version(s): | 6.0.x |
com.atomikos.icatch.feature.<ID>=...It can be set to true or false, and helps us with feature flags for risky code changes so we can always fallback to the previous behaviour.
| Severity: | 3 |
|---|---|
| Affected version(s): | 5.0.x, 6.0.x |
some of our applications occasionally log Exceptions like this during execution:
WARN c.a.j.internal.AtomikosSQLException - The transaction has timed out - try increasing the timeout if needed
WARN c.a.j.i.AtomikosJdbcConnectionProxy - Error enlisting in transaction - connection might be broken? Please check the logs for more information...
com.atomikos.jdbc.internal.AtomikosSQLException: The transaction has timed out - try increasing the timeout if needed
at com.atomikos.jdbc.internal.AtomikosSQLException.throwAtomikosSQLException(AtomikosSQLException.java:29)
at com.atomikos.jdbc.internal.AtomikosSQLException.throwAtomikosSQLException(AtomikosSQLException.java:40)
at com.atomikos.jdbc.internal.AtomikosJdbcConnectionProxy.enlist(AtomikosJdbcConnectionProxy.java:97)
at com.atomikos.jdbc.internal.AtomikosJdbcConnectionProxy.updateTransactionContext(AtomikosJdbcConnectionProxy.java:61)
at com.atomikos.jdbc.internal.AbstractJdbcConnectionProxy.prepareStatement(AbstractJdbcConnectionProxy.java:64)
At first glance, developers thought of an transaction timeout problem, trying to increase the tx-timeout. But in this, timeout increasing did not help. The reason for this exception was previous SQLException which went through a Spring @Transactional method, marking the actual Transaction ‚rollback-only‘.
| Severity: | 3 |
|---|---|
| Affected version(s): | 6.0.x |
| Severity: | 3 |
|---|---|
| Affected version(s): | 6.0.x |
public static RecoverableResource removeResource ( String name )
{
RecoverableResource ret = null;
if ( name != null ) {
ret = (RecoverableResource) resources_.remove ( name );
if ( ret != null ) resourceList_.remove ( ret );
}
return ret;
}
In particular, the additional removal from the resourceList would trigger a call to equals, which in turn expects the XAResource to be available. But this is problematic if the resource was already closed.
Solution: we removed the resourceList since it was not really required.
| Severity: | 4 |
|---|---|
| Affected version(s): | 6.0.x |
What if the "undo" fails?
What if the network blips during the compensation?
What if another process reads the partial data before you’ve rolled it back?
Tags: microservices, saga, xa
]]>Tags: idempotent consumer, microservices, xa
]]>A transaction appears successful in the UI, but was never persisted
A payment is withdrawn but not matched to an invoice
A customer is notified about something that never happened
Systems retry the same operation, causing double processing
If that sounds familiar, you are not alone. Many teams try to mitigate these issues with retries, idempotency keys, or custom rollback logic. But those are workarounds, not guarantees.
And in finance, you need guarantees.
When financial systems get out of sync, you don’t just lose correctness. You lose time, money, and credibility.
Engineers waste time diagnosing edge cases
Operations teams step in to manually reconcile records
Customers file complaints
Auditors start asking hard questions
Eventually consistent systems tend to accrue consistency debt: more compensating logic, more monitoring, and more risk.
As you grow, so do your coordination challenges. Scaling your architecture shouldn't mean scaling your uncertainty.
The alternative is to design for atomic consistency up front: either all steps of a transaction succeed, or none do.
That’s what XA (two-phase commit) protocols were designed for. But traditional XA has a bad reputation: it is too heavy, too slow, too tied to old-school app servers.
That is exactly why we built Atomikos: to bring modern, lightweight transaction coordination to JVM-based systems.
Atomikos lets you:
Coordinate database and messaging operations atomically
Eliminate custom rollback code
Guarantee exactly-once processing
Avoid polling or outbox-based retries
Scale horizontally without giving up control
All without requiring a heavyweight platform or vendor lock-in.
You can even get started with our open source version and upgrade later if you need support or advanced features like LogCloud.
If you are building financial systems, eventual consistency is a liability. It doesn’t fail loudly. It fails subtly, unpredictably, and at scale.
Atomic consistency isn’t old-fashioned. It is table stakes when money, risk, and trust are on the line.
Don’t duct-tape your consistency model. Design it in.
Want to see how Atomikos coordinates messaging and DB in one clean transaction and get eventual consistency done right?
Check this out: https://www.atomikos.com/Blog/TheSimpleSecretOfExactlyOnceDelivery - it works better and it is simpler to do.
Tags: eventual consistency, jms, xa
]]>