Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-06 09:26:52 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
bcquality/microsoft/knowledge/performance/use-single-instance-codeunits-for-caching.md
Jesper Schulz-Wedde 0540c7bf6e Reframe seed-article banners as community contribution invitations 
The 35 articles still in their seed form previously carried a banner
reading "Seed article. ... Domain stewards should expand, restructure,
and refine as needed." For a community preview, that phrasing reads as
"TODO left in production" to first-time visitors.

Replace all three banner variants (performance-seeded, security-seeded,
community-ported) with a single positive invitation:

> Contributions welcome — open a PR to refine or extend this article.

Content and structure of the articles are unchanged; only the leading
quote block differs. Articles that had their banner fully stripped in
the earlier triage pass (the showcase-grade ten) are unaffected.
2026-04-23 17:31:36 +02:00

1.2 KiB
Raw Blame History

bc-version domain keywords technologies countries application-area
all
performance
singleinstance
cache
codeunit
session
al
w1
all

Use SingleInstance codeunits for session caching

Contributions welcome — open a PR to refine or extend this article.

Description

A SingleInstance codeunit lives once per session. Variables on it survive across calls, which makes it the natural home for data that is expensive to compute, read often, and stable for the duration of the session — feature flags, configuration snapshots, setup records. Each cached value avoids a SQL read per subsequent call site.

Best Practice

Store long-lived, read-often, rarely-changing data on a SingleInstance codeunit, populated lazily on first access. Keep the cached footprint small: a handful of booleans, a setup record, a few derived values. Be explicit about invalidation if the source can change during the session.

See sample: use-single-instance-codeunits-for-caching.good.al.

Anti Pattern

Reading the same setup record on every call from every caller, instead of caching it, repeats a SQL round-trip that has no business happening more than once per session.