perf: cache program rule variable option-set mappings (2.41)

[jason-p-pickering]

Problem

DefaultProgramRuleEntityMapperService.getOptions(ProgramRuleVariable) called optionSet.getOptions() fresh on every tracker import that touched the owning program, for every option-set-backed rule variable with useCodeForOptionSet false. OptionSet.options has no L2 collection cache (deliberately, to avoid a different N+1), so every call re-queried optionvalue and re-populated the Option entity cache without ever reading from it — visible on a live instance as ehcache_puts_total{cache="Option"} climbing steadily against a flat ehcache_hits_total, correlated with ProgramRuleAction cache hits, while the option set itself hadn't changed in over a week.

Also directly visible in query-stats profiling as a SELECT ... FROM optionset WHERE optionsetid = ? fired once per rule-variable-mapping pass per option set, because any non-id method call on a Hibernate proxy (like .getOptions()) forces the proxy to fully initialize itself first.

Fix

Memoize the mapped (name, code) list per option set id via a new CacheProvider-backed cache. On a cache hit, the code now only calls optionSet.getId() — which Hibernate special-cases to never trigger proxy initialization — so the optionset row load is skipped entirely instead of just its options collection.

Cache invalidation

Option writes can arrive via DefaultOptionService, the generic metadata CRUD controller, or a metadata import — none of which funnel through a single call site this class could hook into directly to invalidate the cache itself. So invalidation happens at the Hibernate level instead: OptionCacheInvalidationListener is a PostCommit insert/update/delete listener for the Option entity, registered globally via OptionCacheInvalidationListenerConfigurer — the same registration pattern DeletedObjectListenerConfigurer already uses elsewhere in the codebase. On any Option write, it evicts just that option's owning option-set entry.

This is same-node only. A write committed on another node in a cluster isn't seen by this listener, so cross-node staleness still relies on the pre-existing 1h TTL as a backstop.

What this does not fix

Worth being explicit about scope: this only caches the OptionSet → Option leg. It does not touch the separate DataElement proxy load that also shows up in the same query-stats profile (SELECT ... FROM dataelement WHERE dataelementid = ?) — toRuleVariable()/toMappedValueType() call prv.getDataElement().getUid()/.getValueType()/.hasOptionSet() unconditionally on every mapping pass, uncached, regardless of whether an option set is involved. That's a separate N+1 (no cache wraps toMappedProgramRuleVariables() as a whole) and isn't addressed here.

Testing

• ProgramRuleEntityMapperServiceTest updated for the new CacheProvider constructor dependency (was relying on @InjectMocks passing null for anything unmocked, which broke once the constructor started calling cacheProvider.createProgramRuleVariableOptionsCache() eagerly — fixed with explicit construction stubbed with a real SimpleCacheBuilder-backed cache rather than a mock, since a mock stubbed after @InjectMocks already ran is too late).
• New OptionCacheInvalidationListenerTest covers the listener's type/null-guard logic in isolation; mutation-tested (broke the instanceof Option check, confirmed all 5 tests fail correctly, restored).
• Full dhis-service-program-rule module: 41 tests, 0 failures.

🤖 AI Assisted

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud