Course Name: Database administration and

management
Course Code: ICT-503
Credit Hours: 4(3-1)
Topic: (Transaction Isolation Levels )
Level: BS
Lecture # 7
Department of Information Technology , Government College Women University Faisalabad
 Serializable schedules
• If control of concurrent execution is left entirely to the operating
system, many possible schedules, including ones that leave the
database in an inconsistent state, such as the one just described,
are possible. It is the job of the database system to ensure that
any schedule that is executed will leave the database in a
consistent state. The concurrency-control component of the
database system carries out this task. We can ensure consistency
of the database under concurrent execution by making sure that
any schedule that is executed has the same effect as a schedule
that could have occurred without any concurrent execution. That
is, the schedule should, in some sense, be equivalent to a serial
schedule. Such schedules are called Serializable schedules.
 Serializability
• Serializability is the classical concurrency
scheme. It ensures that a schedule for
executing concurrent transactions is
equivalent to one that executes the
transactions serially in some order.
 Transaction Isolation Levels

• Serializability is a useful concept because it allows programmers to ignore

issues related to concurrency when they code transactions. If every
transaction has the property that it maintains database consistency if
executed alone, then serializability ensures that concurrent executions
maintain consistency. However, the protocols required to ensure
serializability may allow too little concurrency for certain applications. In
these cases, weaker levels of consistency are used. The use of weaker
levels of consistency places additional burdens on programmers for
ensuring database correctness.
• The isolation levels specified by the SQL standard are as follows:
• Serializable
• Repeatable read
• Read committed
• Read uncommitted
 Serializable
Serializable usually ensures Serializable
execution. However, as we shall explain shortly,
some database systems implement this isolation
level in a manner that may, in certain cases,
allow nonserializable executions.
 Repeatable
• Repeatable read allows only committed data to be
read and further requires that, between two reads
of a data item by a transaction, no other
transaction is allowed to update it. However, the
transaction may not be Serializable with respect to
other transactions. For instance, when it is
searching for data satisfying some conditions, a
transaction may find some of the data inserted by
a committed transaction, but may not find other
data inserted by the same transaction.
 Read committed
Read committed allows only committed data to
be read, but does not require repeatable reads.
For instance, between two reads of a data item
by the transaction, another transaction may
have updated the data item and committed.
 Read uncommitted
• Read uncommitted allows uncommitted data
to be read. It is the lowest isolation level
allowed by SQL.
 Implementation of Isolation Levels

• So far, we have seen what properties a schedule must have if it is to leave

the database in a consistent state and allow transaction failures to be
handled in a safe manner. There are various concurrency-control policies
that we can use to ensure that, even when multiple transactions are
executed concurrently, only acceptable schedules are generated, regardless
of how the operating system time-shares resources (such as CPU time)
among the transactions. As a trivial example of a concurrency-control
policy, consider this: A transaction acquires a lock on the entire database
before it starts and releases the lock after it has committed. While a
transaction holds a lock, no other transaction is allowed to acquire the lock,
and all must therefore wait for the lock to be released. As a result of the
locking policy, only one transaction can execute at a time. Therefore, only
serial schedules are generated. These are trivially Serializable, and it is easy
to verify that they are recoverable and cascade less as well.
 Locking

• Instead of locking the entire database, a transaction could instead

lock only those data items that it accesses. Under such a policy,
the transaction must hold locks long enough to ensure
serializability, but for a period short enough not to harm
performance excessively. Complicating matters are SQL
statements where the data items accessed depend on a where
clause,
• The two-phase locking protocol, a simple, widely used technique
that ensures serializability.
• Stated simply, two-phase locking requires a transaction to have
two phases, one where it acquires locks but does not release any,
and a second phase where the transaction releases locks but does
not acquire any.
 Types of Locks
• Two kinds of locks:
• Shared
• Exclusive
 Shared and Exclusive

• Shared locks are used for data that the transaction

reads and exclusive locks are used for those it
writes. Many transactions can hold shared locks on
the same data item at the same time, but a
transaction is allowed an exclusive lock on a data
item only if no other transaction holds any lock
(regardless of whether shared or exclusive) on the
data item. This use of two modes of locks along
with two-phase locking allows concurrent reading
of data while still ensuring serializability.
 Timestamps

• Another category of techniques for the implementation of

isolation assigns each transaction a timestamp, typically
when it begins. For each data item, the system keeps two
timestamps. The read timestamp of a data item holds the
largest (that is, the most recent) timestamp of those
transactions that read the data item. The write timestamp of
a data item holds the timestamp of the transaction that
wrote the current value of the data item. Timestamps are
used to ensure that transactions access each data item in
order of the transactions’ timestamps if their accesses
conflict. When this is not possible, offending transactions are
aborted and restarted with a new timestamp.
Multiple Versions and Snapshot Isolation
• There are a variety of multi-version concurrency-control
techniques. One in particular, called snapshot isolation, is
widely used in practice.
• In snapshot isolation, we can imagine that each transaction
is given its own version, or snapshot, of the database when
it begins. It reads data from this private version and is thus
isolated from the updates made by other transactions. If the
transaction updates the database, that update appears only
in its own version, not in the actual database itself.
Information about these updates is saved so that the
updates can be applied to the “real” database if the
transaction commits.
• Snapshot isolation ensures that attempts to read
data never need to wait (unlike locking). Read-only
transactions cannot be aborted; only those that
modify data run a slight risk of aborting. Since each
transaction reads its own version or snapshot of
the database, reading data does not cause
subsequent update attempts by other transactions
to wait (unlike locking). Since most transactions are
read-only (and most others read more data than
they update), this is often a major source of
performance improvement as compared to
locking.