Implicit and explicit locking

If the LN Oracle database driver performs an update, the database can perform the update with implicit or explicit locking.

With implicit locking, before you carry out the UPDATE or DELETE, you do not perform a SELECT FOR UPDATE.

The rows are locked when Oracle performs the update. The UPDATE and DELETE statements do not have a NOWAIT option; therefore, if the resource is locked, the statement and the session to which the statement belong wait until the lock is released or a timeout occurs. If a timeout occurs, the client retries the same operation or rolls back the transaction. If you run an INSERT statement with implicit locking, if the table that the row is to be inserted into is being held with an exclusive lock, the INSERT waits until the lock is released or until a timeout occurs. If a timeout occurs, the client retries the same operation or rolls back the transaction.

With explicit locking, a SELECT FOR UPDATE statement is issued prior to the UPDATE or DELETE, which explicitly locks the required rows. You can run the SELECT FOR UPDATE with the NOWAIT option. With the NOWAIT option, if another process locks the rows, Oracle does not wait for the lock to be released, but returns immediately with an error condition. To use explicit locking for an INSERT statement, you can generate a LOCK TABLE IN ROW SHARE MODE to ensure that the insert will not be blocked. The LOCK TABLE enables the NOWAIT option. With the NOWAIT option, Oracle does not wait for a lock to be released, but returns immediately with an error condition.

Whenever possible, the database driver requests that Oracle use implicit locking. If implicit locking is not possible, the driver requests explicit locking. To change the driver default behavior to use explicit locking, the user can set a flag in the ora_init resource; for more information about this resource, see Database Driver Resources and Environment Variable.