Search Results add_cache_name

Overview

FND_CACHE_VERSIONS_PKG is a low-level Oracle E-Business Suite infrastructure package owned by the APPS schema. It manages version tracking for in-memory or application-level caches used throughout the EBS framework. The package maintains a registry of named caches and a monotonically increasing version number for each, allowing any consumer of a cached value to determine whether the copy it holds is still current. In EBS 12.1.1 and 12.2.2, this pattern supports Oracle Forms sessions, middle-tier Java components, and concurrent programs that need to avoid stale reads without repeatedly querying the underlying base tables.

The package is classified as OTHER in the ETRM repository and is intended for internal framework use. It is not an end-user API and exposes no declarative metadata beyond its documented specification. The header comment identifies revision 120.1, dated 2005, indicating that the specification has been stable across the 11i and R12 release families.

Key Procedures and Functions

• GET_VALUES — Performs a bulk collect operation against FND_CACHE_VERSIONS, loading the current cache registry into a PL/SQL collection for efficient in-process access.
• ADD_CACHE_NAME — Inserts a new entry into FND_CACHE_VERSIONS for the cache identified by the supplied cache name, establishing the initial version record.
• BUMP_VERSION — Increments the stored version number by one for the named cache, signalling to all consumers that any previously cached values are stale.
• GET_VERSION — Returns the current version number for a given cache name. It never raises an exception; if the cache name does not exist, it returns -1. It is declared with PRAGMA RESTRICT_REFERENCES (WNDS, TRUST), so it may be called from SQL contexts.
• CHECK_VERSION — The API most commonly sought when searching for "check_version." It accepts a cache name and an IN OUT version parameter, compares the caller's version against the persisted current version, and returns a Boolean. If the caller's version is current, the function returns TRUE and no cache refresh is required. If a newer version exists, the function returns FALSE and updates the IN OUT parameter with the current version, providing the caller the correct key for retrieving the refreshed value from cache. Like GET_VERSION, it never raises exceptions and carries the WNDS/TRUST restrictions, allowing use in SQL and constrained PL/SQL contexts.

Tables Accessed

The package operates on FND_CACHE_VERSIONS through APPS synonyms. This table is the persistent registry holding each cache name and its current version counter. All five documented routines either read from it, write to it, or both. The ETRM metadata additionally lists PLITBLM, a standard PL/SQL inter-language table used internally for bulk operations, which supports the bulk collect performed by GET_VALUES.

Usage Notes

Typical invocation follows a read-check-refresh pattern. A component first calls GET_VERSION or GET_VALUES to establish its baseline, then periodically calls CHECK_VERSION with its held version. A FALSE return instructs the component to re-read the underlying data and retain the newly returned version value. Whenever the underlying data changes, the owning process calls BUMP_VERSION so that all participants detect the change on their next check. ADD_CACHE_NAME is executed during setup or registration of a new cache.

Because the routines are WNDS-restricted and never raise exceptions, they are safe to embed in Forms triggers, concurrent program logic, OAF/ADF business component code, and custom PL/SQL that must interrogate the cache state opportunistically. The package is referenced by few or no other documented packages, confirming its role as a shared utility rather than a business-rule engine.