shashank created CAMEL-26770:
--------------------------------
Summary: camel-sql - JdbcCachedMessageIdRepository: a key added in
a transaction that rolls back stays in the cache
Key: CAMEL-26770
URL: https://issues.apache.org/jira/browse/CAMEL-26770
Project: Camel
Issue Type: Bug
Components: camel-sql
Reporter: shashank
Assignee: shashank
JdbcCachedMessageIdRepository.add puts the key in its in-memory cache as soon
as super.add returns, before the transaction that inserted the row commits.
When the add joins a caller's transaction (a transacted route on the same
DataSource transaction manager) and that transaction rolls back, the row is
gone but the key stays in the cache. add() and contains() then answer from the
cache, so the redelivery of the same message is rejected as a duplicate,
although the database has no row for it.
CAMEL-24046 made add() cache the key only after the insert succeeded; this is
the case where the insert succeeds but the caller's transaction then rolls back.
Found by Claus Ibsen while reviewing CAMEL-26743 (apache/camel#29437), where
JdbcOrphanLockAwareIdempotentRepository had the same pattern for its keep-alive
set; that PR now adds the key only after the commit (a
TransactionSynchronization). The same approach would work here. (remove() and
clear() empty the cache before their transaction commits, but a rolled-back
remove only costs a cache miss, as contains() then reads the row.)
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
