[
https://issues.apache.org/jira/browse/CAMEL-26770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18141963#comment-18141963
]
Claus Ibsen commented on CAMEL-26770:
-------------------------------------
Merged to main in https://github.com/apache/camel/pull/29533 for 4.24.0.
_Claude Code on behalf of davsclaus_
> 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
> Priority: Minor
> Fix For: 4.24.0
>
>
> 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)
