bharos commented on PR #12171: URL: https://github.com/apache/gravitino/pull/12171#issuecomment-5097141573
> Also load-tested on a large schema (25 concurrent listers + 25 creators): `create_table` went from 0 completions in 5 min to ~1,450, with list latency unchanged. Thanks @nevzheng for the review. addressed in the latest commit, and updated the Cache safety section accordingly. SegmentedLock now keeps a per-stripe generation counter, bumped on every relation-cache eviction. The batch read snapshots the relation's generation right after the miss (before the backend call) and, under the per-key lock, skips the cache.put if the generation changed , so a concurrent invalidation can't be overwritten. On a skip the slot is left absent and rebuilt on the next read (a miss, never a stale hit), so a later single-key listEntitiesByRelation reads fresh from the backend instead of returning stale A. On your exact ordering: Direct invalidate (your table): the generation bump runs under the same stripe lock as the populate, so they're fully serialized : the populate either runs before the invalidate (which then evicts it) or sees the changed generation and skips. Cascade invalidate (entity K is evicted as a side-effect of invalidating a related key - e.g. an owner change evicts every co-owned table's owner entry through the reverse index): that eviction runs under the related key's lock, not K's, so it can still race K's populate. The guard bumps K's generation on eviction too, closing all but the narrow gap between the guard's generation check and its write. This race isn't introduced here , that cascade path never held K's populate lock on main either; the guard only shrinks it. Went per-stripe rather than per-key to reuse the existing striping and avoid an unbounded, non-self-pruning per-key map; the only cost is a benign false-skip when unrelated keys share a stripe (a miss, never a stale hit). Added the ordering test you asked for testBatchListSkipsPopulateWhenInvalidatedDuringBackendCall PTAL -- 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]
