Search Results gmi_locks




Overview
Explore in AI Chat

Overview

GMI_LOCKS is an APPS-owned PL/SQL package within the Oracle E-Business Suite Process Manufacturing (OPM) product family. Its principal business function is to provide a centralized locking mechanism for inventory records residing in the Process Manufacturing inventory tables. The package ensures that concurrent users or concurrent programs do not simultaneously modify the same inventory location or warehouse records, thereby protecting data integrity during high-volume transactional activity such as reservations, shipping, and batch migration.

The package is classified under the "OTHER" API category in the ETRM metadata, indicating that it is not a public, supported integration API but rather an internal utility package invoked by other OPM application modules. The dependency listing confirms that GMI_LOCKS is an actively referenced component within the OPM inventory and order fulfillment stack, with GMI_RESERVATION_UTIL, GMI_SHIPPING_UTIL, and MIGRATE_BATCH all depending upon it.

Its status is recorded as VALID in both Oracle EBS 12.1.1 and 12.2.2, confirming continued availability across these releases. The package draws on Oracle's built-in DBMS_LOCK facility to implement its serialization logic, which is characteristic of a low-level concurrency-control utility rather than a business-facing API.

Key Procedures and Functions

The ETRM metadata documents seven procedures and functions within the package specification and body. The only named routine exposed in the available documentation is LOCK_INVENTORY, which is the primary entry point through which calling modules request a lock on inventory data. The remaining routines are not individually documented in the excerpt provided; consistent with the metadata, they should be understood as supporting internal helpers that acquire, release, or verify lock state rather than as independently callable business APIs.

The typical contract of LOCK_INVENTORY is to accept a caller-supplied identifier (for example, a warehouse or locator reference) and to attempt to secure an exclusive lock against that resource. If the lock cannot be obtained, the routine would be expected to signal a failure condition to the caller, allowing the calling utility to defer or abort the operation. No parameter lists are documented in the ETRM metadata, and therefore none should be assumed.

Tables Accessed

Three dependencies are documented for GMI_LOCKS. The first two are the OPM inventory base tables IC_LOCT_INV (inventory locator/lot records) and IC_WHSE_MST (warehouse master). These are the tables whose records the package serializes access to; the lock manager reads them to validate the existence and identity of the inventory location or warehouse being locked. The third dependency is the Oracle-supplied DBMS_LOCK package, which supplies the actual enqueue-based locking primitives used to implement the serialization.

No insert, update, or delete activity against the inventory tables is implied by the package's documented purpose; its role is to read and gate access rather than to modify inventory data. The referencing relationships confirm this: GMI_LOCKS is invoked by reservation, shipping, and migration utilities immediately before those utilities perform their own DML against the same inventory records.

Usage Notes

GMI_LOCKS is an internal utility and is not typically invoked from Oracle Forms, concurrent program parameters, or customer-written code directly. Its documented callers are GMI_RESERVATION_UTIL, GMI_SHIPPING_UTIL, and MIGRATE_BATCH, all of which are OPM inventory and order-management modules. Customers should not build custom integrations against this package, as it is not a supported public API and its interface may change without notice.

The package is most likely reached during reservation of on-hand inventory, during shipping confirmation and delivery processing, and during data migration or batch conversion operations that write to OPM inventory tables. Because the lock is implemented via DBMS_LOCK, administrators investigating contention, blocking sessions, or "unable to lock" errors in OPM inventory flows should treat GMI_LOCKS as a prime candidate for the source of the enqueue wait, and should review concurrent execution of the three dependent utilities.