Concurrency, in a multi-user database system, refers to the ability of multiple users to
correctly run multiple transactions simultaneously.
The role of the concurrency control manager, then, is to coordinate these users and their
transactions so that they can all complete in the most efficient way possible, while
maintaining system stability.
The basic purpose of a lock is to allow data items to be read/written in a mutually
exclusive manner, so as to prevent any other processes from accessing a data item and
causing a serializability issue.
Four conditions must be met for deadlock to exist. If one of these does not hold true,
then there is no deadlock.
The first condition for deadlock is the “mutual exclusion condition.” This
condition states that only one process can hold a resource at a time and requires that at
least one transaction holds an exclusive-mode lock.
The second condition that must be met for deadlock to occur is the “hold and
wait” condition. This condition states that transactions that are holding data items can
request others, but the data items being requested are held by other transactions. For
example, Transactiond holds dataw but also requests datax, which is currently held by
Transactione.
Condition three is the “no pre-emption” condition, and it says that once a data
item is under the control of a transaction, it cannot be forcibly taken away. The
transaction has use of it until it releases the lock.
The last condition for deadlock is the “circular wait” condition. In circular wait,
each transaction is waiting for the use of a data item held by another transaction. So, if
Transactiona is holding datap and cannot continue until it also holds dataq, there is
deadlock if Transactionb holds dataq and is waiting on datap.
Starvation results when a transaction is stuck in the queue and can never move up and
have the opportunity to execute its tasks. Starvation sometimes occurs as the result of a
continuous stream of shared-mode locks. Since shared-mode locks are granted
immediately upon request, a transaction that is waiting for an exclusive-mode lock may
have to wait a significant length of time until the shared-mode locks are all granted, and
subsequently released.
The “strict two-phase locking protocol” and the “rigorous two-phase locking
protocol” both have more detailed rules for the holding and releasing of locks. The
“strict” version forces the transaction to hold all exclusive-mode locks until the
transaction commits. The “rigorous” version wants the transaction to hold all locks
until it commits.
A benefit of the timestamp-based protocol is that it prevents starvation from occurring.
Since every transaction has a turn, there is no possibility of infinite waiting.
There is a possibility that a database system may deal with mostly reads and just an
occasional write.
When this is the case, there really is not a need for a complex
concurrency-based protocol since there is only a slim chance of any sort of conflict.
Instead, the third concurrency control protocol, a validation-based monitoring system,
is used.
In order to accomplish view serializability, two schedules must first be view equivalent.
A transaction schedule is view equivalent to a serial schedule if, after rearranging the
steps of the transactions to attain a serial schedule, resulting data values are still found
in the same manner
There is a process referred to as a blind write that prevents a view-serializable schedule
from also being conflict serializable. A blind write is basically just a write done on a
data item that was not first read by the transaction. It seems difficult to transform a
schedule that contains blind writes into a conflict serializable schedule, since it appears
that the location of blind writes in a schedule are important to the schedule executing
properly.
If we have two schedules, they are said to be final-state equivalent if they involve the
same transactions and they have identical mappings between states for every possible
combination. Unfortunately, this is a very general definition and it is nearly impossible
to test it against every single possible combination, as the definition suggests.