Keep owner directory searches fresh after record changes - #3
ivanmilevtues wants to merge 4 commits into
Conversation
CodeBoarding reviewStatus: 4 changed components See the full change in CodeBoarding. graph LR
n_owner["owner"]
n_vet["vet"]
n_system["system"]
n_model["model"]
n_Loose_files_in_src_main_java_org_springframework_samples_petclinic["Loose files in src.main.java.org.springframework.samples.petclinic"]
n_owner -- "calls" --> n_system
n_owner -- "calls" --> n_model
classDef added fill:#1f883d,stroke:#0b5d23,color:#ffffff;
classDef modified fill:#bf8700,stroke:#7d4e00,color:#ffffff;
classDef deleted fill:#cf222e,stroke:#82071e,color:#ffffff,stroke-dasharray:5 3;
class n_owner,n_system modified;
linkStyle 0 stroke:#0b5d23,stroke-width:2px;
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: df1c58481e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| * @return a Collection of matching {@link Owner}s (or an empty Collection if none | ||
| * found) | ||
| */ | ||
| @Cacheable(CacheOperations.OWNER_SEARCH_CACHE) |
There was a problem hiding this comment.
Each distinct (lastName, Pageable) supplied to GET /owners now creates a permanent cache entry, but the configured Caffeine cache has neither a maximum size nor an expiry policy. Because every entry retains a full page of eager owner/pet/visit aggregates, ordinary varied searches—or requests deliberately using unique search strings and page numbers—can grow the heap without bound until the application is restarted or the entire cache is manually cleared. Configure an eviction limit/TTL or restrict which searches are cached.
Useful? React with 👍 / 👎.
| if (cache == null) { | ||
| return false; | ||
| } | ||
| cache.clear(); |
There was a problem hiding this comment.
When a cache-miss search overlaps a mutation, the search can read the old database state, the mutation can commit and execute this clear, and the search's @Cacheable interceptor can then publish its old Page after the clear has completed. That stale result remains indefinitely because the cache has no expiry and no further invalidation is guaranteed, so the synchronous clear does not actually ensure fresh searches under concurrent requests. Use a generation/versioned key or otherwise coordinate cache population with writes.
Useful? React with 👍 / 👎.
1 participant
Summary
Why
Front-desk searches can otherwise return stale owner aggregates after contact details, pets, or visits change. Centralizing cache operations gives support staff a direct diagnostic path while ensuring every owner aggregate mutation refreshes subsequent searches.
Validation
./mvnw testArchitecture note
Owner aggregate mutation handling now calls the cache operations boundary directly so search consistency is enforced synchronously.