Package org.objectweb.transaction.api.lock

Specification of the Lock API.

See:
          Description

Interface Summary
ConflictLockCheckFeature Feature providing a way of checking if two LockMode are conflicting.
ExclusiveLockFeature Definition of an exclusive Lock.
LockIdentifier Defines the interface of a Lock identifier.
LockMode Particular Event dealing with different kind of lock mode.
LockQueueState State describing a queue of acquired locks.
ModeLockFeature Definition of a mode Lock.
ReleaseLockFeature Abstract Feature Definition for a Lock Feature.
 

Package org.objectweb.transaction.api.lock Description

Specification of the Lock API.

Table of contents

  1. About Locking
  2. Lock Policies
  3. Lock Dependencies
  4. Example

This part includes only the interfaces dealing with the purpose of locks. This means mainly that only Consistency properties are considered in this part.

About Locking

Locking ensures the consitency of accessed data. Before accessing a data, the system request the lock associated to this data. If the lock is available, the request is satisfied and the system can access the data. If the lock is not available, the system should wait for the release of this lock before following its execution. Usually, the lock is released when the system do not use the data anymore. But in the context of transaction, the lock is released after the completion of the transaction.

When implementing transactional locking, we considered the three criteria as follows:

  1. When a lock is requested, we need an efficient way of checking whether a conflicting lock is already held by another transaction.
  2. When a lock is released, transactions that requested conflicting locks earlier and have therefore been suspended should now be considered for being resumed.
  3. When a transaction terminates, all locks (still) held on behalf of the transaction are released at once.

There are also other points to consider:

Lock Models

Read/Write Model (R/W Model)

Locked\Requested Read Write
Read Yes No
Write No No

Two transactions can share a r/w lock by having it acquired in non-conflicting modes (two reads). If a lock is acquired by a transaction in the write mode, if another transaction is going to acquire a lock in the read or write (both are conflicting with write) modes, it suspended until the conflicting write lock is released.

As for supended waiting requests, a single queue of suspended lock requests is sufficient. However, it is also possible to have separate R and W queues as in MySQL: The locking method MySQL uses for WRITE locks works as follows:

The locking method MySQL uses for READ locks works as follows: When a lock is released, the lock is made available to the threads in the write lock queue, then to the threads in the read lock queue. This means that:

The r/w model often considers other locks related to read and write operations. This includes:

Note that even in the r/w model with the update lock mode as an extension, the conflict table is not symmetric

Lock Dependencies

Example