Search Results okc_k_entity_locks_u1

Overview

The OKC.OKC_K_ENTITY_LOCKS table is a transactional data object within the Oracle E-Business Suite Contracts (OKC) schema. It functions as a concurrency-control and locking registry, recording which contracts or contract-related entities hold a lock against another entity at any given point in time. In the context of ETRM (Enterprise Contracts) 12.1.1 and 12.2.2, this table underpins the prevention of conflicting concurrent edits to contract documents, deliverables, and their associated entities. Applications running across a multi-user EBS deployment consult this table to determine whether a requested lock can be granted or must be denied because another user or process already owns it.

From a Data Vault modeling perspective, the heuristic classification of this object is standalone. It does not participate in a foreign-key hub or link relationship to other documented tables; instead it is a self-contained lock registry whose business identity is expressed through a composite of entity name and primary-key values rather than through referential integrity constraints. The absence of database-level FK dependencies is significant: enforcement of referential semantics is delegated to the application layer (the OKC PL/SQL APIs and the OKC_K_ENTITY_LOCKS# package), not to the RDBMS.

Key Information Stored

The table comprises sixteen documented columns. The most consequential are as follows:

• K_ENTITY_LOCK_ID — The surrogate primary key (OKC_K_ENTITY_LOCKS_PK) and the column governed by the unique index OKC_K_ENTITY_LOCKS_U1. This is a system-generated NUMBER that uniquely identifies each lock record.
• ENTITY_NAME, ENTITY_PK1 … ENTITY_PK5 — The business-key candidate identifying the locked entity. ENTITY_NAME carries the logical entity type (up to 240 characters), while ENTITY_PK1 through ENTITY_PK5 hold the concatenated primary-key values of the target object. These five columns form the flexible, polymorphic identifier used to lock any OKC entity without a rigid FK.
• LOCK_BY_ENTITY_ID, LOCK_BY_DOCUMENT_TYPE, LOCK_BY_DOCUMENT_ID — Identify the lock owner. LOCK_BY_DOCUMENT_TYPE and LOCK_BY_DOCUMENT_ID point to the document or contract that requested the lock, enabling the system to associate a lock with its originating contract.
• OBJECT_VERSION_NUMBER — Supports optimistic locking and version tracking, a standard EBS 12.2.x concurrency mechanism.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — The standard EBS WHO columns capturing audit and session provenance for each lock grant, renewal, or release.

The unique index OKC_K_ENTITY_LOCKS_U1 enforces uniqueness on the surrogate key. Non-unique indexes NU1 through NU4 support lookups by entity name and PK components and by lock owner, reflecting the principal access paths used by the locking APIs.

Common Use Cases and Queries

Typical use cases include diagnosing lock contention during contract authoring, auditing stale locks that were not released after a session termination, and reporting lock ownership across a contract portfolio. The following patterns are representative:

• Retrieve all locks held by a given contract:
  SELECT * FROM OKC.OKC_K_ENTITY_LOCKS WHERE LOCK_BY_DOCUMENT_ID = :doc_id AND LOCK_BY_DOCUMENT_TYPE = :doc_type;
• Investigate whether a specific entity is locked:
  SELECT * FROM OKC.OKC_K_ENTITY_LOCKS WHERE ENTITY_NAME = :name AND ENTITY_PK1 = :pk1;
• Detect stale locks by age:
  SELECT K_ENTITY_LOCK_ID, ENTITY_NAME, LAST_UPDATE_DATE FROM OKC.OKC_K_ENTITY_LOCKS WHERE LAST_UPDATE_DATE < SYSDATE - :threshold_hours;
• Join lock records to contract headers (via LOCK_BY_DOCUMENT_ID against OKC_K_HEADERS_B.ID) to present lock owner and contract number side by side for operational dashboards.

Reports are commonly built as Oracle Reports or BI Publisher extracts filtered by ENTITY_NAME to isolate locks on a particular entity class, which assists administrators in clearing orphaned locks through supported APIs rather than direct DML.

Related Objects

The documented metadata records no incoming or outgoing foreign-key dependencies, and OKC_OKC_K_ENTITY_LOCKS is referenced only by the package OKC_K_ENTITY_LOCKS#. In practice, the following objects are significant to its operation and are commonly joined by application code or reporting queries:

• OKC_K_ENTITY_LOCKS# — The PL/SQL package that encapsulates lock acquisition, release, and validation logic against this table.
• OKC_K_HEADERS_B — Contract header table; join on LOCK_BY_DOCUMENT_ID = OKC_K_HEADERS_B.ID where LOCK_BY_DOCUMENT_TYPE matches the header type, to resolve lock ownership to a contract number.
• OKC_K_LINES_B — Contract line table; contracted entities locked in this table frequently correspond to line-level records.
• OKC_K_ITEMS — Contract deliverable/item definitions often referenced through ENTITY_NAME and ENTITY_PK values.
• FND_USER — Join on CREATED_BY or LAST_UPDATED_BY to identify the user holding or releasing a lock.
• FND_LOGINS — Join on LAST_UPDATE_LOGIN to correlate lock activity with a specific EBS session.

Because the table is standalone from a referential standpoint, administrators should treat all maintenance as API-driven and consult the OKC_K_ENTITY_LOCKS# specifications before attempting any corrective action.