wenzhenghu commented on code in PR #65126:
URL: https://github.com/apache/doris/pull/65126#discussion_r3541916724
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/metacache/MetaCacheEntry.java:
##########
@@ -228,42 +307,125 @@ private V getWithManualLoad(K key, Function<K, V>
loadFunction) {
return value;
}
- long generation = invalidateGeneration.get();
- V loaded = loadAndTrack(key, loadFunction);
- if (generation != invalidateGeneration.get()) {
- return loaded;
+ long generation;
+ // Snapshot generation only after re-checking the cache under the
publication lock so
+ // public mutations cannot slip between the miss observation and
the captured version.
+ synchronized (publishLock(key)) {
+ value = data.asMap().get(key);
+ if (value != null) {
+ return value;
+ }
+ generation = generationOf(key);
}
-
- // Keep null results uncached so manual miss load matches
LoadingCache null-return behavior.
+ V loaded = loadAndTrack(key, loadFunction);
if (loaded == null) {
return null;
}
- // Leave a narrow hook for tests to pause exactly before the cache
put race window.
Review Comment:
Thanks a lot for the careful review and for calling out this path.
After re-checking the implementation, I believe the same-key manual miss
load is still deduplicated by `synchronized (loadLock(key))`. The slow
`loadAndTrack(...)` call is executed inside that critical section, while
`publishLock(key)` is only used to protect the short publication window before
and after the load.
So my current understanding is that concurrent misses for the same key
should still be serialized by `loadLock`, and `publishLock` is an additional
safeguard for stale write-back rather than a replacement for the
load-deduplication lock.
Please let me know if you are seeing a different path than this one.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
