[
https://issues.apache.org/jira/browse/CAMEL-26770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-26770 started by shashank.
----------------------------------------
> 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
>
> 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)
