Search Results okc_k_entity_locks

Overview

The OKC_K_ENTITY_LOCKS table resides in the OKC schema, which underpins the Contracts Core (OKC) module of Oracle E-Business Suite. Its purpose is to serialize concurrent modifications to contract-related entities by recording advisory lock rows against a logical entity identified by an entity name and a composite primary key. When a user or concurrent program attempts to modify a contract, contract line, or related business object, EBS inserts or checks a row in this table so that a second session cannot simultaneously process the same entity. This mechanism protects contract versioning, terms, and line-level edits from lost updates and inconsistent state.

The documented ETRM classification assigns this object a standalone Data Vault heuristic, meaning it does not exhibit the foreign-key fan-in or fan-out that would identify it as a hub, link, or satellite. In practice it is best modelled as a transaction-oriented lock registry: the surrogate key is independent, and the target entity is referenced through a polymorphic (name plus PK parts) pattern rather than a typed foreign key. This is a modelling suggestion rather than a physical constraint, and it explains why the table has no documented foreign keys to the contract tables it protects.

Key Information Stored

The table is documented with sixteen columns in the 12.2.2 physical schema. The most significant are:

• K_ENTITY_LOCK_ID — the surrogate primary key, enforced by OKC_K_ENTITY_LOCKS_PK and also by the unique index OKC_K_ENTITY_LOCKS_U1. This is the single business-key candidate documented for the table.
• ENTITY_NAME — identifies the type of entity being locked (for example, a contract header or line), driving the polymorphic reference.
• ENTITY_PK1 through ENTITY_PK5 — the composite primary key values of the locked entity, allowing any of the contract tables to be addressed by the same lock structure.
• LOCK_BY_ENTITY_ID — the identifier of the entity holding the lock, enabling self-referential detection of the locking session's context.
• LOCK_BY_DOCUMENT_TYPE, LOCK_BY_DOCUMENT_ID — identify the document that owns the lock, typically the contract document performing the update.
• OBJECT_VERSION_NUMBER — the standard EBS optimistic locking column, incremented on each update.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard Who columns providing audit lineage for lock acquisition and release.

Common Use Cases and Queries

Administrators and support analysts use OKC_K_ENTITY_LOCKS to diagnose "record locked" errors, identify sessions holding stale locks, and confirm whether a concurrent request has released a contract. A typical diagnostic query lists active locks for a specific contract:

• SELECT k_entity_lock_id, entity_name, entity_pk1, lock_by_document_id, last_update_date FROM okc.okc_k_entity_locks WHERE entity_pk1 = :contract_id;
• SELECT entity_name, COUNT(*) FROM okc.okc_k_entity_locks GROUP BY entity_name ORDER BY 2 DESC; — surface entities with the highest lock contention.
• SELECT * FROM okc.okc_k_entity_locks WHERE last_update_date < SYSDATE - 1; — detect potentially orphaned locks left by terminated sessions.

Reporting use cases include concurrency trending, auditing amendment activity against high-value contracts, and validating that the lock table does not accumulate unbounded rows after batch contract import.

Related Objects

Because the table uses a polymorphic reference, joins are value-based rather than FK-based. Significant related objects include OKC_K_HEADERS (joined on ENTITY_PK1 when ENTITY_NAME denotes a contract header), OKC_K_LINES (contract lines), OKC_K_HEADERS_B and OKC_K_LINES_B (base tables backing the headers and lines), OKC_K_VERSION_HISTORY and OKC_K_STATUS_HISTORY for lifecycle tracking, and the OKC_CONTRACT_PUB and OKC_TERMS_UTIL packages that perform lock acquisition and release. Reporting views such as OKC_K_HEADERS_V and OKC_K_LINES_V are commonly combined with this table when investigating contention.