yuqi1129 commented on code in PR #13099:
URL: https://github.com/apache/gravitino/pull/13099#discussion_r4003085431
##########
core/src/main/java/org/apache/gravitino/cache/CaffeineEntityCache.java:
##########
@@ -335,7 +335,12 @@ private <KEY, VALUE> Caffeine<KEY, VALUE>
newBaseBuilder(Config cacheConfig) {
}
if (cacheConfig.get(Configs.CACHE_EXPIRATION_TIME) > 0) {
- builder.expireAfterAccess(
+ // Expire after write, not after access. The TTL is the safety net for a
cross-node
+ // invalidation that never arrives (a lost entity_change_log row, a
stalled poller). With an
+ // access-based TTL a stale entry that keeps being read would never
expire, so a single missed
+ // invalidation would become permanent on exactly the hottest keys. A
write-based TTL bounds
+ // that staleness to expireTimeInMs.
+ builder.expireAfterWrite(
cacheConfig.get(Configs.CACHE_EXPIRATION_TIME),
TimeUnit.MILLISECONDS);
Review Comment:
Thanks for pointing this out. I agree that there is a race between the
asynchronous removal listener and reinserting the same key into
`cacheData`/`cacheIndex`. However, this race already exists in the current
cache-index maintenance logic and is not introduced by the `expireAfterAccess`
to `expireAfterWrite` change in this PR. This PR is intentionally scoped to
aligning the configured TTL semantics with the documented write-based
expiration. I suggest tracking the listener/index race in a separate issue and
addressing it in a focused follow-up with dedicated concurrency coverage.
--
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]
