Search Results generic_1to1_get_value

Overview

FND_PLSQL_CACHE is a server-side PL/SQL package body owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. Its business function is to provide a centralized, in-memory caching framework for PL/SQL sessions within the EBS application tier. Rather than repeatedly querying reference data such as application definitions, responsibilities, and user context information, EBS code can load that data once into a session-level cache managed by this package and retrieve it on subsequent calls at negligible cost. The package is a foundational internal utility; it is classified as OTHER in the ETRM directory and is not part of the public, certificated integration API surface, but it underpins performance for many framework components. In the documented dependency metadata, the package body compiles to a VALID status in the APPS schema and references a small, stable set of dependencies, which is consistent with a low-level infrastructure package that must remain available even when higher-level application code is being patched or recompiled.

Key Procedures and Functions

The ETRM extract documents 27 procedures and functions organized into two families: a generic cache engine and a custom cache engine. Each family supports two storage models: one-to-one (1TO1) key/value mappings and one-to-many (1TOM) key-to-collection mappings.

• Generic procedures: GENERIC_CACHE_NEW_VALUE, GENERIC_1TO1_INIT, GENERIC_1TO1_GET_VALUE, GENERIC_1TO1_PUT_VALUE, GENERIC_1TO1_REMOVE_KEY, GENERIC_1TO1_CLEAR, GENERIC_1TO1_DEBUG, GENERIC_1TOM_INIT, GENERIC_1TOM_GET_VALUES, GENERIC_1TOM_PUT_VALUES, GENERIC_1TOM_REMOVE_KEY, GENERIC_1TOM_CLEAR, and GENERIC_1TOM_DEBUG. These expose a reusable, type-agnostic cache in which a caller initializes a named cache region, stores and retrieves values, removes individual keys, clears an entire region, and emits diagnostic output through the DEBUG entry points.
• Custom procedures: CUSTOM_1TO1_INIT, CUSTOM_1TO1_GET_GET_INDEX, CUSTOM_1TO1_GET_PUT_INDEX, CUSTOM_1TO1_REMOVE_KEY, CUSTOM_1TO1_CLEAR, CUSTOM_1TO1_DEBUG, and CUSTOM_1TOM_INIT. The custom variants allow a developer to bind a cache to specific lookup logic and index positions rather than relying on the generic accessor pattern, supporting specialized retrieval needs while reusing the underlying cache storage and lifecycle management.

The naming convention makes the respective roles explicit: INIT establishes the cache structure, GET/GET_VALUES read from it, PUT/PUT_VALUES write to it, REMOVE_KEY deletes a single entry, CLEAR resets the structure, and DEBUG supports troubleshooting.

Tables Accessed

The documented dependency list identifies FND_APPLICATION, FND_APPLICATION_VL, FND_GLOBAL, FND_RESPONSIBILITY_VL, DBMS_UTILITY, PLITBLM, DBMS_STANDARD, and STANDARD as referenced objects. Among these, the ETRM table extract specifically records FND_APPLICATION, DBMS_UTILITY, and PLITBLM as the tables accessed through APPS synonyms.

• FND_APPLICATION / FND_APPLICATION_VL: the application definition and its translated view, used to resolve application identifiers and names.
• FND_RESPONSIBILITY_VL: the translated responsibility view, consulted when cache keys relate to responsibility-level context.
• FND_GLOBAL: the standard EBS package that returns session attributes such as user, responsibility, and application, which the cache uses to scope entries to the correct runtime context.
• DBMS_UTILITY, PLITBLM, DBMS_STANDARD, STANDARD: Oracle-supplied PL/SQL infrastructure packages required for compilation and runtime support.

Consistent with its role as a memory-resident cache, the package is primarily read-oriented against these dictionary and context objects; the cache itself is held in PL/SQL memory structures rather than in application tables.

Usage Notes

FND_PLSQL_CACHE is invoked internally by the EBS framework and by custom PL/SQL that needs fast, repeated access to reference data. Typical invocation points include Oracle Forms-based responsibilities, concurrent program logic, OAF/BC4J middleware, and custom stored procedures that follow EBS coding standards. The ETRM metadata shows the package is referenced by 11 other packages while not being referenced by any database object; this confirms its position as a shared dependency rather than an entry-point API called directly from the user interface layer.

Because the cache is session-scoped, its contents do not persist across database sessions and should not be treated as a durable store. Developers using the generic or custom entry points should initialize a cache region before use and clear or remove entries when underlying reference data changes, since stale cached values can otherwise persist for the life of the session. The DEBUG procedures are intended for development and diagnostic use only and are not recommended in production paths. Any customization that calls this package should be treated as a direct dependency on an Oracle-internal component; such code should be validated during EBS patching and upgrades, including the 12.1.1 to 12.2.2 transition, because internal framework packages are subject to change without the notice applied to public APIs.