Logical Locks 

By using logical locks, you can lock single rows or generic areas of database tables. There are write locks and read locks. For one object you can set a maximum of one write lock, but multiple read locks. Read and write locks are mutually exclusive. For this reason, read locks are also called shared locks, and write locks are also called exclusive locks. The locking protocol determines which locks are set for which type of access and at which point in time. All applications have to use the locking protocol that has been specified for the corresponding table. This section deals with two possible locking protocols.

 

Locking protocol 1

Only write locks are set. If you want to change an object in a transaction, the application requests a write lock for this object at the start of the transaction. If the object is already locked, the application cannot run in change mode, but in display mode only. Since no read locks can be set, objects can always be read (as long as the isolation level of the database allows this, which is usually the case – see above). This locking protocol guarantees the highest level of parallelism and scalability.

 

Locking protocol 2

Read and write locks are set. When an object is read by the database, a read lock is set. If you want to change an object, a write lock is requested. If a write lock cannot be set because a read or write lock has been set, the application has to decide whether to cancel the transaction or to try again later. The write lock can be requested immediately when you change the object, or shortly before the end of the transaction. The advantage of requesting a write lock at an early stage is that you can inform users in time. On the other hand, the advantage of requesting a write lock at a later stage is that the lock is set for a short time only, which enables a higher level of parallelism and scalability. This is due to the fact that by setting a write lock, you prevent the object from being read in another transaction. If you request a write lock at a later stage, make sure that you request a read lock when you change the object at the latest. This ensures that the object cannot be changed in another transaction.

All applications that access a particular table have to use the agreed locking protocol.

If two applications try to get locks for multiple objects simultaneously but in a different sequence, dead locks occur. To avoid this, an exception is triggered if a lock cannot be set.