Enqueue Locks 

Enqueue Locks Semantics

Enqueue locks are server-side logical locks. The Enqueue Server does not communicate with persistent storage such as databases, file systems, and so on. It records locks currently in use within its internal central lock table in main memory. To modify shared data,applications request the Enqueue Server to set an appropriate lock. The Enqueue Server checks whether the lock request collides with an existing lock. If not, it sets the lock. If the lock request does collide with an existing lock, the Enqueue Server rejects it.

Each locking request implies remote communication between the application and the Enqueue Server. Applying appropriate lock granularity helps reduce network traffic. For example, you can embed wildcard characters into locking arguments to block entire areas of business objects in a single lock request.

Enqueue locking offers the following advantages to database locking:

●      If a lock collision occurs, the Enqueue Server throws an exception, thus enabling applications to react immediately

●      You can run the underlying database on the lowest transaction isolation level

●      Enqueue locks are portable among DBMS supported by SAP NetWeaver AS Java

Enqueue Locks Guidelines

●      Enqueue locking applies both to the SAP NetWeaver AS Java system database and external databases supported by SAP NetWeaver AS Java.

●      All application components must rely on enqueue locking. Locking will work if all components rely on the same locking principle.

●      All application components must commit to apply the same locking protocol.

●      With enqueue locking, JDBC data sources must operate on the lowest, READ_UNCOMMITTED transaction isolation level.

●      Enqueue locking works with Open SQL, Native SQL, and Vendor SQL.

●      To obtain an enqueue lock, you must have an active JTA or database transaction

●      We recommend that you choose and use one persistence API consistently:

With ORM technologies such as EJB CMP and JDO, you do not need to set locks explicitly. Both frameworks implicitly lock persistent objects by default.

In all other cases, you set and release enqueue locks using the interfaces of the Locking Adapter Service:

¡        To lock specific database items you use the TableLocking API.

¡        In all other cases, you use the LogicalLocking API.

·        We recommend that you set locks only when necessary and for as short a time as possible. To release locks you use one of the following approaches:

○       To release locks in the application, you use the dedicated methods of the TableLocking and LogicalLocking APIs.

○       Locks exist within the scope of a transaction. When a transaction ends, the AS Java automatically releases the locks set during the transaction.

·        To manage, test, and view statistics about enqueue locks, you use the Locking Adapter Service. For more information, see Managing Locks in the Administration Manual.

See also:

Working with Enqueue Locks.