|
|||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
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. |
Specification of the Lock API.
This part includes only the interfaces dealing with the purpose of locks. This means mainly that only Consistency properties are considered in this part.
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:
There are also other points to consider:
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 r/w model often considers other locks related to read and write operations. This includes:
Locked\Requested | Read | Update | Write |
Read | Yes | Yes | No |
Update | No | No | No |
Write | No | No | No |
Use of this lock mode prevents deadlocks in case that multiple transactions are reading some data, decide which data to update, and then update selected data. In this case, transaction share the data thanks to sharing the read lock acquired, but they are deadlocked when waiting for the write (exclusive) lock since the other read locks have to be released. Update lock solve this problem thanks to it is not conflicting with read, but it is conflicting with itself and also read is conflicting with it. Therefore, there can be only one transaction that acquired the lock in the update mode, which prevents new update or read locks acquired. Before going to write (to convert the update mode to the write mode), the transaction just has to wait for reads acquired before.
Locked\Requested | Read (S) | Write (X) | Read Intention (IS) | Write Intention (IX) | Read + Write Intention (SIX) |
Read (S) | Yes | No | Yes | No | No |
Write (X) | No | No | No | No | No |
Read Intention (IS) | Yes | No | Yes | Yes | Yes |
Write Intention (IX) | No | No | Yes | Yes | No |
Read + Write Intention (SIX) | No | No | Yes | No | No |
These locks are used in locking with different granularity. E.g., in relational databases, we can lock a single record or whole table. To indicate that it is not possible to lock a table in the write mode when there is one of its records locked in the read (or write) mode, we lock the table by the intention-read (intention-write mode). An equivalent of the update lock is the read-intention-write mode.
Note that even in the r/w model with the update lock mode as an extension, the conflict table is not symmetric
|
|||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |