Object Locking

Object locking is an optional Oracle database component. It is intended only for development databases and must not be installed or enabled in production.

How it works

The fixed NEXO_SQL_STUDIO owner stores a versioned changeset ledger, active locks, audit events, protected schemas, users, configuration, and full DDL history. Locks default to 12 hours; DDL history defaults to 60 days. A scheduler job removes expired data.

Nexo sets Oracle CLIENT_IDENTIFIER to the signed-in Nexo account identity. When no Nexo identity is available, the component falls back to Oracle SESSION_USER. The first lock automatically registers that effective identity. A lock owner can unlock their own object; a configured locking administrator can force-unlock another user’s object after confirmation.

Every bundled database change has an ordered changeset ID, component version, and SHA-256 checksum. Nexo reports the component as missing, ready, outdated, inaccessible, partial, or newer than the installed extension. Applied checksums are immutable: checksum drift, partial installations, and newer database versions require DBA review rather than an automatic downgrade.

Installation and upgrades

Installation and upgrades require a privileged DBA connection and explicit review. Nexo can preview and run the bundled installer through its SQL script runtime, or generate the complete script for a system administrator. The fixed owner needs permission to create its tables and PL/SQL, create the cleanup scheduler job, and install the database-level DDL trigger. The installer also publishes the limited locking API needed by developer sessions.

Before running a generated script, the DBA must choose a strong owner password, an existing permanent tablespace, quota and retention appropriate for the expected DDL volume, and the administrators allowed to force-unlock objects. The history table stores full DDL as CLOB data, so its storage must be monitored even though the default cleanup window is 60 days.

The database trigger can block compilation or DDL from Nexo SQL Studio, SQL Developer, SQLcl, CI, migration tools, and deployment services when another developer owns the target lock. For that reason, do not install or enable this component in production.

Enabling schema protection

Folder settings inherit to nested folders and override connection settings. Enabling or disabling the option changes database-wide protection for that connection schema. Lock owners may unlock their own objects; configured administrators may force unlock after confirmation.

Any Nexo user can change protection for an existing non-Oracle-maintained schema through this setting. System, Oracle-maintained, APEX, ORDS, and NEXO_SQL_STUDIO schemas are rejected. Because disabling the setting affects every tool and developer using that schema, teams should control who may edit shared connection and folder settings.

Right-click a supported object in the connection tree to lock it for the configured 12-hour period. The tree shows the active owner and expiry. Owners see Unlock object, administrators see a confirmed Force unlock object action for foreign locks, and other users see the foreign lock as read-only.

Operations and recovery

The LOCKING_ENABLED configuration value is the emergency global enforcement switch. A DBA can also disable protection for an individual schema, promote a trusted identity to locking administrator, remove an expired or abandoned lock, or disable the database trigger while investigating a failure. These actions should be audited and locking should be re-enabled only after the blocking condition is understood.

The cleanup job removes expired locks and DDL history older than DDL_HISTORY_RETENTION_DAYS. Monitor scheduler failures, invalid objects in NEXO_SQL_STUDIO, tablespace growth, and changeset state. Never edit an applied changeset or its ledger checksum; install later changesets sequentially when Nexo reports that an update is available.