Search Results i_item_id

Overview

GMI_LOCKS is a PL/SQL package body owned by APPS in the Oracle E-Business Suite, delivered as part of the Process Manufacturing (OPM) modules. Its purpose is to serialize access to inventory rows held in the IC_LOCT_INV table during allocation activity in the Oracle Manufacturing / Oracle Order Management (OM/OPM) integration. When an allocation session begins for a specific item, warehouse, lot, lot status, and location, the procedures in GMI_LOCKS place locks that prevent other sessions from simultaneously accessing the same inventory. This guards against double allocation of identical stock, and it eliminates deadlocks between concurrent sessions by enforcing a consistent locking sequence.

Although not exposed as an end-user feature, the package is a critical concurrency control component. The user search term "i_item_id" reflects GMI_LOCKS' internal use of item identifiers as the primary key element by which inventory is selected and locked. The package is classified in ETRM metadata as API classification OTHER, indicating it is an internal utility rather than a public documented interface.

Key Procedures and Functions

The documented procedures and functions total seven, all centered on the single named routine LOCK_INVENTORY. The package intentionally overloads LOCK_INVENTORY so that calling code can invoke the same routine name with different parameter sets depending on the granularity of locking required. Documented overload variants accept:

• Item
• Item and Warehouse
• Item, Warehouse, Lot, and Lot Status
• Item, Warehouse, and Location
• Item, Warehouse, Lot, Lot Status, and Location

These variants return a Boolean status: TRUE when inventory rows are locked successfully, FALSE when the rows are already locked by another user (in which case the caller should retry later). A further variant provides additional control for callers needing explicit retry behavior. It adds a Retries parameter that specifies how many times the routine attempts locking at one-second intervals before giving up. For that variant the possible return values are TRUE (rows locked successfully), FALSE (rows locked by another user, try later), and NULL (no rows locked because none matched the supplied parameters). The NULL return is documented as potentially significant; the other overloads return TRUE when no matching rows are found.

Parameter lists are not enumerated here, consistent with the documented metadata.

Tables Accessed

GMI_LOCKS references three underlying objects, via APPS synonyms:

• IC_LOCT_INV — the primary target of the locking logic. Rows in this inventory-by-location table are locked at the start of an allocation session to reserve stock.
• IC_WHSE_MST — the warehouse master, consulted in the warehouse-scoped variants to resolve and validate warehouse context before locking.
• DBMS_LOCK — the Oracle-supplied locking package, used to obtain and manage the lock resources.

Usage Notes

GMI_LOCKS is invoked programmatically rather than through a maintenance form. Its documented callers are the allocation logic in OM/OPM integration, and ETRM records three other packages that reference it. Typical invocation occurs from within an allocation session, immediately before inventory is allocated, with the caller selecting the overload that matches the required lock granularity (item alone up to the full item/warehouse/lot/status/location combination). Callers that require fine-grained control use the retry variant to govern contention behavior. Developers extending or troubleshooting allocation flows in Oracle EBS 12.1.1 or 12.2.2 should treat GMI_LOCKS as an internal concurrency utility whose behavior is driven by the item ("i_item_id"), warehouse, lot, lot status, and location keys supplied by the caller.