allthingssecurity commented on PR #29669:
URL: https://github.com/apache/camel/pull/29669#issuecomment-6818055193
Thanks for the review. Both points are in 9ba4115dd24e.
1. Window closed in this PR, with your counter. Every eviction after a
delete bumps it before the key leaves the cache: in `remove` (only when it
deleted a row), in `clear`, and in the after-commit eviction of a caller
transaction. `add` reads it before its SELECT, merges, and removes the key
again if it moved. Three additions were needed:
- The cache hit of `add` is now one `computeIfPresent`. Before, a key
evicted between the `getOrDefault` and the `merge` was put back, the same stale
key on the hit path.
- An `add` of a key later in the same transaction as its `remove` cancels
that remove's pending eviction. Without this, the after-commit eviction bumps
the counter and drops the key that `removeAndAddInOneCallerTransactionIsCached`
expects to stay cached (the row is there again at the commit). A clear followed
by an add in one transaction keeps the eviction, so that key is only not cached.
- `reload()` reads the counter around its query and starts with an empty
cache if a remove or clear ran meanwhile. It had the same query-then-assign
shape.
Tests: `addOnAnotherThreadThatReadTheRowBeforeARemoveIsNotCached` and
`...BeforeAClearIsNotCached`. The row is in the table but not in the cache, so
the add on the other thread really reads it inside an open transaction; the
remove or clear runs and evicts; then that transaction commits and caches the
key. Both fail on f3e4faeb14ba's class (`contains` stays true) and pass now.
camel-sql: 374 run, 0 failures (without `SqlFunctionDataSourceTest`, embedded
MariaDB). The two cached-repository test classes: 280/280 over 20 runs in one
JVM.
Limits, also stated in the Javadoc and the description: this holds with
read committed. A caller transaction under snapshot isolation that reads a
snapshot older than the counter is not covered, and neither is one without
Spring transaction synchronization.
2. Added to "Caching Jdbc IdempotentRepository" (catalog copy identical): a
`remove` or `clear` in a transaction takes the key (or the keys) out of the
cache again when that transaction commits, and an add that read the row before
it was deleted does not keep the key in the cache.
The description is updated.
_Claude Code on behalf of allthingssecurity_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
