Search Results okc_k_entity_locks_s

Overview

The APPS.OKC_K_ENTITY_LOCKS_PKG package body is a component of the Oracle E-Business Suite Contracts (OKC) module, which underpins the Oracle Contracts Core and the Service Contracts (OKS) family of applications. Its principal business function is to manage the persistence of entity-level lock information for contract objects. In the Contracts data model, a contract — whether a service agreement, subscription, warranty, or other contract type — is represented as a hierarchy of related entities (the contract header, parties, line items, price lines, and so on). When concurrent business processes or application sessions need to prevent conflicting updates to these entities, they register a lock against the specific entity instance using a well-defined entity name and primary key combination. This package provides the specialized DML layer that inserts and removes those lock records, acting as the sanctioned programmatic entry point rather than allowing direct manipulation of the underlying tables.

The package is classified as a non-public ("OTHER") API in ETRM metadata. Notably, the source uses the _K_ middle segment in its name, which in Oracle naming conventions indicates a kernel or low-level infrastructure component as opposed to a user-facing API. It is intended to be invoked by other internal Contracts packages rather than called directly by end-user code.

Key Procedures and Functions

ETRM documents two procedures within this package body:

• INSERT_ROW — Creates a new entity-lock record. It accepts an entity name together with one or two entity primary key values that identify the specific contract entity to be locked, and writes a corresponding row into the locking tables. This is the mechanism by which a session claims a lock over a contract entity before performing sensitive modifications.
• DELETE_ROW — Removes an entity-lock record, effectively releasing the previously claimed lock. Releasing locks is essential to avoid orphaned lock entries that could block subsequent legitimate processing or cause incorrect concurrency behavior.

The package declares a substantial set of global constants inherited from the standard Oracle APIs Toolkit, including G_FND_APP, G_APP_NAME, and the standard return-status constants (G_RET_STS_SUCCESS, G_RET_STS_ERROR, G_RET_STS_UNEXP_ERROR). It also defines amendment codes G_AMEND_CODE_DELETED, G_AMEND_CODE_ADDED, and G_AMEND_CODE_UPDATED. The search term g_amend_code_updated corresponds directly to the constant G_AMEND_CODE_UPDATED defined at line 34 with the value 'UPDATED'. These amendment codes allow the package to classify the nature of a change against a locked entity, an important consideration in versioning and amendment-tracking scenarios. Debugging support is provided through G_DBG_LEVEL and the FND_LOG level constants.

Tables Accessed

Two tables are referenced through APPS synonyms, evidently forming a base table and its corresponding secondary or audit table:

• OKC_K_ENTITY_LOCKS — The primary lock repository, storing one row per active entity lock.
• OKC_K_ENTITY_LOCKS_S — The companion table following the Oracle _S convention, typically used to hold the current effective version of records or shadow/audit copies tracked through amendment processing.

The coexistence of an amendment-code constant (G_AMEND_CODE_UPDATED) with the _S table strongly suggests the package participates in Oracle's standard shadow-table versioning model, where inserts and deletes are mirrored with appropriately tagged amendment codes.

Usage Notes

Because the package is documented as referenced by one other package and is classified as non-public, it is an internal dependency rather than an interface invoked by Oracle Forms or concurrent programs directly. The typical invocation path is indirect: higher-level Contracts APIs, such as contract authoring, amendment, or termination logic, call OKC_K_ENTITY_LOCKS_PKG.INSERT_ROW when acquiring a lock and DELETE_ROW when releasing it. Custom extensions should not call these routines in isolation unless they faithfully replicate the surrounding transactional and lock-management context; direct DML against OKC_K_ENTITY_LOCKS is strongly discouraged in favor of the packaged procedures. When troubleshooting lock contention or stale lock records in EBS 12.1.1 and 12.2.2, the package body — particularly the constants and FND_LOG statements — is the appropriate starting reference point.