shashank created CAMEL-26868:
--------------------------------
Summary: camel-sql - JdbcCachedMessageIdRepository: a key removed
in a transaction of the caller can stay in the cache after its row is deleted
Key: CAMEL-26868
URL: https://issues.apache.org/jira/browse/CAMEL-26868
Project: Camel
Issue Type: Bug
Components: camel-sql
Reporter: shashank
Assignee: shashank
{{JdbcCachedMessageIdRepository.remove}} (and {{clear}}) removes the key from
its cache before and after the delete. When the repository is used in a
transaction of the caller on the same DataSource (or JTA), the delete joins
that transaction and is only committed later: for example a direct {{remove}}
or {{clear}} in a transaction, or the idempotent consumer removing the key of a
failure that a dead letter channel handled inside an enclosing transaction that
commits. Until then, another thread still sees the row: its {{add}} of the key
finds the row, returns false (a duplicate) and caches the key. When the
caller's transaction commits, the row is gone but the key stays in the cache,
so every later {{add}} of that key is rejected as a duplicate without a row,
until the cache is reloaded (a restart).
Expected: once the remove is committed, the key is not in the cache.
Possible fix: also remove the key from the cache in the {{afterCommit}} of the
caller's transaction (a transaction synchronization, as {{add}} uses since
CAMEL-26770 to cache a key only after its row is committed).
Found in the review of CAMEL-26770 (apache/camel#29533), from reading the code;
confirmed with a test (H2: remove in an open transaction on one thread, add on
another, then commit).
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
