Search Results get_system_lock

Overview

APPS.BSC_LOCKS_PUB is a public PL/SQL package that implements the concurrency control and locking framework used throughout the Oracle EBS Balanced Scorecard (BSC) module. Its principal business function is to ensure that only one user or one background process modifies a given scorecard object at any point in time, thereby preventing lost updates and inconsistent reads while a save operation is in progress. The header comment documents the core design intent: when a user enters a user interface flow, the package verifies that the object being modified is not already locked as a top-level object. If a conflicting lock exists, the value currently held in the database is stale, and the caller is instructed to wait until the save completes before proceeding. The package is therefore central to the integrity of interactive and batch edits against scorecards, objectives, measures, dimensions, calendars, and related configuration objects.

Key Procedures and Functions

The ETRM metadata lists eleven documented procedures and functions. The most closely associated with the search term is GET_SYSTEM_LOCK, which retrieves an existing lock record for a given object so that callers can inspect lock ownership, session information, or lock status before attempting an operation. It exists alongside a similarly named GET_SYSTEN_LOCK (a historical spelling variant preserved in the code base), GET_SYSTEN_LOCKS, and GET_SYSTEM_TIME, which returns server or system time used for lock aging and comparison.

CHECK_SYSTEM_LOCK performs the primary validation: it confirms that an object is not locked as a top-level object and raises an application error when a conflicting lock is found. Its documented parameters include the object key, object type, program ID, application user ID, and a cascade lock level whose default of -1 enables cascade locking down to the lowest level. CHECK_SYSTEM_LOCKS provides the equivalent check for multiple objects in a single call. SYNCHRONIZE coordinates lock state between the calling process and the persistent lock tables. REMOVE_SYSTEM_LOCK releases a lock when the owning process completes or aborts its transaction, and the getter routines support diagnostics and administrative inspection of lock state. The documented object types include OVERVIEW_PAGE, SCORECARD, CUSTOM_VIEW, LAUNCHPAD, OBJECTIVE, MEASURE, DATA_COLUMN, DIMENSION, DIMENSION_OBJECT, REPORT, CALENDAR, PERIODICITY, and TABLE, while the program ID constants distinguish UI and backend Data Loader sessions, generate database and documentation jobs, administrator, Objective Designer, Builder, Performance Scorecard, system upgrade, and system migration contexts.

Tables Accessed

The package reads and writes the BSC lock tables that persist concurrency state: BSC_OBJECT_LOCKS stores the active top-level lock records, BSC_OBJECT_LOCK_USERS records the users associated with those locks, and BSC_CURRENT_SESSIONS tracks live sessions for lock ownership and cleanup. BSC_DB_TABLES, BSC_KPIS_B, BSC_TABS_B, BSC_TAB_VIEWS_B, BSC_SYS_CALENDARS_B, BSC_SYS_DATASETS_B, BSC_SYS_DIM_GROUPS_TL, BSC_SYS_DIM_LEVELS_B, BSC_SYS_MEASURES, and BSC_SYS_PERIODICITIES supply object identity and metadata used to resolve and validate lock targets across the supported object types. FND_MENUS is referenced for menu or function context, and DBMS_STATS is available for statistics maintenance. These objects are accessed through APPS synonyms, consistent with standard EBS naming and the APPS schema ownership shown in the metadata.

Usage Notes

BSC_LOCKS_PUB is invoked primarily from the Balanced Scorecard forms and user interface flows at the point where a user begins editing an object, and again during save and exit processing to acquire and then release locks. Concurrent programs such as the Data Loader, Generate Database, and system migration or upgrade routines call the same package with the backend program ID constants. Five other packages reference BSC_LOCKS_PUB, confirming its role as a shared service API rather than a private implementation detail. Custom code that manipulates BSC objects should call CHECK_SYSTEM_LOCK before modification and REMOVE_SYSTEM_LOCK afterward, honoring the cascade lock level semantics to avoid leaving stale locks. The package behaves consistently across Oracle EBS 12.1.1 and 12.2.2, subject to the standard APPS schema and synonym configuration in each environment.