Question
Platform Cache Session partition concurrency and Manage Platform Cache permission boundary
Cig Echo
0 reputation · 02 Sept 2026, 06:13 UTC
88.8K views
Loading…
0 reputation · 02 Sept 2026, 06:13 UTC
Design goal is to use Session Cache to avoid repeated expensive computation when several Apex requests for the same user arrive concurrently.
Platform Cache provides Org Cache and Session Cache partitions configured in Setup. Session Cache is scoped to the authenticated user session and is invalidated when the session ends. Apex Cache.Org and Cache.Session have no built-in per-key lock or atomic get-or-compute operation. TTL for Org Cache is best-effort and eviction can occur under memory pressure without application notification. Creating or editing cache partitions requires the Manage Platform Cache permission; Apex read/write access depends on partition visibility settings.
The permission boundary and concurrency behavior are unclear for a design that expects a single recomputation per session key under load.
Does Manage Platform Cache permission control Apex read/write access to an existing Session partition, or only partition creation and configuration? Is duplicate recomputation under concurrent misses the documented behavior for Session Cache? What guarantees, if any, exist for key-level consistency during simultaneous put operations within the same session?
35275 reputation · 02 Sept 2026, 11:44 UTC
Manage Platform Cache permission controls partition creation and editing in Setup. It does not gate Apex read or write access to an existing Session Cache partition. Runtime Apex access is governed by the partition's visibility setting and by whether the partition is marked visible to Apex.
Duplicate recomputation under concurrent misses is expected behavior. Cache.Session has no built-in per-key lock and no atomic get-or-compute operation. If multiple requests for the same user miss the same key at the same time, each request can independently run the expensive computation and call put(). Salesforce does not document this as a guaranteed behavior, but it follows from the absence of cache-level locking.
No key-level consistency guarantee exists for simultaneous put() operations on the same Session Cache key within one session. A later put() can overwrite an earlier one, but Salesforce does not document a last-write-wins contract or any isolation level for concurrent writes.
Confirmed: Manage Platform Cache is a Setup-level permission for partition configuration. Session Cache is scoped to the authenticated user session and is invalidated when the session ends. Apex Cache.Session exposes get(), put(), contains(), and remove() only; there is no compare-and-set or lock primitive.
Uncertain: Whether Salesforce internally serializes writes to a single Session Cache key under high concurrency is not publicly documented. Treat the cache as eventually consistent at best, and assume eviction can occur under memory pressure without notification.
Do you require exactly-one recomputation per session key, or is duplicate computation acceptable if the result is deterministic and side-effect free? This determines whether you need external locking or can treat cache misses as non-critical recomputation.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 02 Sept 2026, 09:43 UTC
One caveat not covered above: Cache.Session has no configurable TTL, so a value written by one request stays visible to subsequent requests in the same session until the session ends or the key is removed. Under concurrent misses, the first put() to land wins for the rest of the session, but there is no guarantee about which concurrent execution that will be.
If the computation is not strictly user-specific, evaluate Cache.Org with a user-agnostic key to deduplicate work across sessions; if it is user-specific, keep the compute path idempotent. To verify partition access in your org, check Setup > Platform Cache for Apex visibility and confirm the running user’s profile or permission set is included.
salesforce