Databases Reference
In-Depth Information
concurrently. More advanced schedule algorithms base the schedules on serial
use of resources rather than simply on serializing the transactions. This allows
for concurrent transactions, as long at the transactions do not require the same
resources.
There are a couple of problems inherent in transaction scheduling. One is
the performance loss because of the serialized transactions. The other problem
is the overhead required to schedule the transactions and to manage transaction
processing.
Timestamp ordering
is another schedule-based concurrency management
method that preserves the transaction order. It uses a timestamp protocol that
manages transaction processing to ensure that the transaction order is preserved.
As each transaction is entered for execution, it is given a timestamp value. This
is typically taken down to the level of the individual statements, with each state-
ment given either a read timestamp or write timestamp, as appropriate. Access
to individual resources is serialized, based on timestamp order.
The potential problems are similar to those described earlier for transaction
scheduling. Delays caused by serialization are less pronounced because serializa-
tion is managed at the statement level rather than the transaction level, but longer
running transactions can still delay completion of shorter transactions. Also, sched-
uling and management carry a significant amount of processor resource overhead.
Locking is the method most commonly used by current DBMS versions.
While one transaction is accessing a resource it places a
lock,
an access restric-
tion, on the resource, controlling the level of access allowed by another trans-
action. There are two basic types of locks. A
shared lock
is used to manage read
access. When one transaction places a shared lock on a resource, other transac-
tions can access the same resource, but only for read access. An
exclusive lock
is used with write access. When a transaction places an exclusive lock on a
resource, no other transaction is able to access the resource. Many DBMSs set a
default
transaction isolation level,
which sets the locking level automatically
during transaction processing.
You also have control over the
lock scope
or
locking level.
This refers to
the specific resource that is locked. Most DBMSs support different locking lev-
els, letting you lock the database, a table, or even an individual row. The more
granular the locking level, the smaller the scope of the lock, the less interference
with other transactions.
The use of exclusive locks effectively serializes the transactions during write
operations, blocking other transactions' access until the write operation is com-
plete. This is also the biggest potential drawback to this method, that a trans-
action's access to resources it needs can be blocked. If the blocking transaction
is also a long-running transaction or is delayed for some reason, it could cause
the
blocked transaction
to time out, resulting in an error. A blocked transac-
tion is one that cannot continue because it cannot access the resources it needs.
