fix: remove L2 cache on the OptionSet.options collection to avoid tracker import N+1 - #24811
Draft
jason-p-pickering wants to merge 2 commits into
Draft
fix: remove L2 cache on the OptionSet.options collection to avoid tracker import N+1#24811jason-p-pickering wants to merge 2 commits into
jason-p-pickering wants to merge 2 commits into
Conversation
jason-p-pickering
changed the title
…cker import N+1 Live Glowroot trace on a 2.41 dev server showed an intermittent N+1 during tracker import: thousands of individual `SELECT ... FROM optionvalue WHERE optionvalueid = ?` in a single request. Root cause is a collection-cache-hit plus entity-cache-miss combination: when OptionSet.options' L2 collection cache still has a cached id list but the individual Option entities' L2 cache has evicted (region-wide L2 eviction is not per-key), Hibernate resolves each id one at a time instead of re-running the plain `WHERE optionsetid = ?` collection query. Removing only the collection-level cache on OptionSet.options makes Hibernate always take that cheap collection-query path, since there's no cached id list left to reconcile against the entity cache. Entity-level caching on Option/OptionSet themselves is unrelated to this mechanism and is left in place. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
jason-p-pickering
force-pushed
the
fix/2.41-option-optionset-l2-cache-removal
branch
from
August 8, 2026 08:10
163a330 to
256107f
Compare
jason-p-pickering
marked this pull request as draft
August 14, 2026 16:00
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
/trackerimport: thousands of individualSELECT ... FROM optionvalue WHERE optionvalueid = ?in a single request.OptionSet.options' L2 collection cache can hold a cached list of option IDs while the individualOptionentities' L2 cache has separately evicted (region-wide L2 eviction is not per-key). When that happens, Hibernate resolves each ID one at a time instead of re-running the plainWHERE optionsetid = ?collection query — which is fast (~1.4ms, indexed FK) and is what a second trace confirmed as the normal/fast path.<cache>on theOptionSet.optionsbag. With no cached id list to reconcile against the entity cache, the collection always loads via its own single query — there's no cached/uncached combination left to produce the N+1.<cache usage="read-write">onOptionandOptionSetthemselves is left in place — it's unrelated to this mechanism and still useful for other lookup paths (e.g. resolving a many-to-one reference). An earlier version of this PR removed those too, conflating this fix with a separate, unvalidated idea (a service-layer replacement cache) that isn't part of this change.Test plan
xmllint --noouton the edited.hbm.xmlfile (well-formedness, no stray--in comments)dhis-service-core+dhis-test-integrationbuild cleanly with the new mapping2.41)🤖 AI Assisted