yuqi1129 commented on issue #11737:
URL: https://github.com/apache/gravitino/issues/11737#issuecomment-5043031282

   Tracking refinement after reviewing the design and the current 
implementation.
   
   New subtasks:
   
   - #12149 defines a shared, default-deny cache eligibility policy and audits 
action-sensitive and connector-backed entities.
   - #12150 adds explicit fresh/cache-bypass reads for consistency-sensitive 
operations.
   - #12151 makes change-log emission transactionally complete across cacheable 
entity types and mutation paths.
   - #12152 batches tag/policy inheritance relation reads and adds executable 
database-performance acceptance criteria.
   
   Existing implementation subtasks remain:
   
   - #11961 removes generic relation-list caching.
   - #12018 implements an entity-type allowlist. Its decisions must be 
reconciled with the broader policy audit in #12149 before either issue closes, 
especially for metalake state, policy/job data, and connector-backed 
schema/table data.
   - #12019 wires Caffeine to cross-node change-log invalidation.
   - #12020 provides the optional Redis implementation, subject to an explicit 
DB/cache failure contract.
   
   Correctness dependencies:
   
   - #11736 must not be treated as fully resolved by listener retry alone. PR 
#11739 explicitly leaves the auto-increment commit-order gap as a known 
limitation; the entity-cache design needs either prevention or a documented 
fail-safe/bounded-staleness contract.
   - #10739 / #10740 fixed invalidation-before-write ordering. A load that 
starts before a post-commit invalidation can still finish and refill stale data 
afterward, so `get`, `batchGet`, rename/drop, and hierarchical invalidation 
need a deterministic late-fill test and a fence if the race remains.
   
   The epic should close only when Caffeine's bounded-eventual semantics, 
fresh-read paths, mutation-event coverage, poller failure behavior, late-fill 
behavior, and multi-node tests are all explicit and verified. A shared Redis 
copy should not be described as strongly consistent with the database unless 
write ordering and failure behavior make that guarantee precise.
   


-- 
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]

Reply via email to