Search Results hxc_lock_api




Overview
Explore in AI Chat

Overview

HXC_LOCK_API is a PL/SQL application programming interface owned by the APPS schema in Oracle E-Business Suite. Within the ETRM (Enterprise Time and Labor Management) module, it provides the central mechanism for acquiring, validating, and releasing concurrency locks over time-related business objects. Its principal role is to prevent two users or processes from simultaneously editing or transacting against the same record — most notably time building blocks and timecard or self-service transactions in Oracle Time and Labor (OTL). By serializing access to these resources, the package safeguards data integrity across overlapping updates, time entry submissions, and approval processing.

The package is declared AUTHID CURRENT_USER, meaning it executes with the privileges of the calling schema rather than those of its owner. This supports its use across multiple internal OTL/self-service components without granting blanket privileges. It is documented as an API classification object, and its logic centers on a lock repository held in the HXC_LOCKS table.

Key Procedures and Functions

The package exposes a documented set of procedures organized around the lock lifecycle. Note that the two public REQUEST_LOCK overloads differ in their success output: one returns a BOOLEAN, the other a VARCHAR2, the latter provided for self-service (SS) use where the caller consumes a textual result. The documented procedures are:

  • REQUEST_LOCK — Acquires a lock on a specified resource. The caller supplies a process/locker type, and optionally resource, start/stop time, time building block identifiers (with object version number for optimistic concurrency), transaction lock identifier, and an expiration time. It returns the lock row identifier and a success indicator, along with any diagnostic messages. This is the primary entry point for claiming exclusive access before an update.
  • CHECK_LOCK — Determines whether a lock currently exists or remains valid for a given resource. It allows callers to test lock status before proceeding, avoiding blocked or conflicting operations.
  • RELEASE_LOCK — Releases a previously acquired lock once the protected operation completes, freeing the resource for other users or processes. This is the counterpart to REQUEST_LOCK and the procedure most relevant to a "release_lock" search.

Tables Accessed

The package reads and writes the following tables through APPS synonyms:

  • HXC_LOCKS — The core lock repository. Rows represent active locks, including the locked resource, locker type, expiration, and association identifiers. REQUEST_LOCK inserts or updates here; CHECK_LOCK queries it; RELEASE_LOCK removes or clears the corresponding entry.
  • HXC_TIME_BUILDING_BLOCKS — The time entry construct that is frequently the locked resource, particularly in OTL self-service timecards. Locks protect individual building blocks from concurrent edits.
  • HXC_AP_DETAIL_LINKS — Links approval or application detail records to their underlying transactions, used to resolve which objects are subject to locking during approval flows.

Usage Notes

HXC_LOCK_API is invoked programmatically rather than through a standalone concurrent program. It is called by Oracle self-service time and approval forms and by internal OTL APIs to establish and clear locks around update operations. Custom extensions and integrations that manipulate time building blocks or timecard transactions should follow the same discipline: call REQUEST_LOCK before modification, honor the returned success and expiration values, and always call RELEASE_LOCK in completion or exception handlers to prevent stale locks. Because the package is referenced by nine other packages, changes to its behavior can affect timecard entry, approval, and transfer processing. The documented default expiration (via hxc_lock_util) ensures abandoned locks eventually become reclaimable, so custom code need not manage lock timeouts manually.