Transactions Management

Database System Concepts, 7th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Outline

▪ Transaction Concept
▪ Transaction State
▪ Concurrent Executions
▪ Serializability
▪ Recoverability
▪ Implementation of Isolation
▪ Transaction Definition in SQL
▪ Testing for Serializability.

Database System Concepts - 7th Edition 17.2 ©Silberschatz, Korth and Sudarshan
 Introduction

▪ Quite often databases are dynamic in the sense that the data stored in them are
frequently being altered, either by addition, deletion or modification.
▪ Whenever any of these alterations happen, we say that a transaction has
occurred in the database.
▪ Transactions are inevitable and are important in the management of databases
especially in the preservation of the integrity and accuracy of the database.
▪ This module examines the concept of database transactions, the features of a
transaction and how a database management system handles transactions to
preserve database integrity and consistency.

Database System Concepts - 7th Edition 17.3 ©Silberschatz, Korth and Sudarshan
 Transactions
▪ The term transaction refers to a collection of operations that form a single
logical unit of work. For instance, transfer of money from one account to another
is a transaction consisting of two updates, one to each account.
▪ It is important that either all actions of a transaction be executed completely, or,
incase of some failure, partial effects of a transaction be undone. This property is
called atomicity.
▪ Further, once a transaction is successfully executed, its effects must persist in the
database—a system failure should not result in the database forgetting about a
transaction that successfully completed. This property is called durability.
▪ In a database system where multiple transactions are executing concurrently, if
updates to shared data are not controlled there is potential for transactions to see
inconsistent intermediate states created by updates of other transactions. Such a
situation can result in erroneous updates to data stored in the database.
▪ Thus, database systems must provide mechanisms to isolate transactions from
the effects of other concurrently executing transactions. This property is called
isolation.

Database System Concepts - 7th Edition 17.4 ©Silberschatz, Korth and Sudarshan
 Transaction Concept

▪ A transaction is a unit of program execution that accesses and possibly

updates various data items.
▪ E.g., transaction to transfer $50 from account A to account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
▪ Two main issues to deal with:
• Failures of various kinds, such as hardware failures and system
crashes
• Concurrent execution of multiple transactions

Database System Concepts - 7th Edition 17.5 ©Silberschatz, Korth and Sudarshan
 Transaction Example

▪ For the time being, we assume that the database permanently resides on disk, but
that some portion of it is temporarily residing in main memory.
▪ Transactions access data using two operations:
• read(X), which transfers the data item X from the database to a local buffer
belonging to the transaction that executed the read operation.
• write(X), which transfers the data item X from the local buffer of the
transaction that executed the write back to the database.
▪ In a real database system, the write operation does not necessarily result in the
immediate update of the data on the disk; the write operation may be temporarily
stored in memory and executed on the disk later.

Database System Concepts - 7th Edition 17.6 ©Silberschatz, Korth and Sudarshan
 Example of Fund Transfer

▪ Transaction to transfer $50 from account A to account B:

1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
▪ Atomicity requirement
• If the transaction fails after step 3 and before step 6, money will be “lost”
leading to an inconsistent database state
▪ Failure could be due to software or hardware
• The system should ensure that updates of a partially executed transaction
are not reflected in the database
▪ Durability requirement — once the user has been notified that the transaction
has completed (i.e., the transfer of the $50 has taken place), the updates to the
database by the transaction must persist even if there are software or hardware
failures.

Database System Concepts - 7th Edition 17.7 ©Silberschatz, Korth and Sudarshan
 Example of Fund Transfer (Cont.)

▪ Consistency requirement in above example:

• The sum of A and B is unchanged by the execution of the transaction
▪ In general, consistency requirements include
• Explicitly specified integrity constraints such as primary keys and foreign
keys
• Implicit integrity constraints
• A transaction must see a consistent database.
• During transaction execution the database may be temporarily
inconsistent.
• When the transaction completes successfully the database must be
consistent
▪ Erroneous transaction logic can lead to inconsistency

Database System Concepts - 7th Edition 17.8 ©Silberschatz, Korth and Sudarshan
 Example of Fund Transfer (Cont.)

▪ Isolation requirement — if between steps 3 and 6, another transaction T2

is allowed to access the partially updated database, it will see an
inconsistent database (the sum A + B will be less than it should be).

T1 T2
1. read(A)
2. A := A – 50
3. write(A)
read(A), read(B), print(A+B)
4. read(B)
5. B := B + 50
6. write(B
▪ Isolation can be ensured trivially by running transactions serially
• That is, one after the other.
▪ However, executing multiple transactions concurrently has significant
benefits, as we will see later.

Database System Concepts - 7th Edition 17.9 ©Silberschatz, Korth and Sudarshan
 ACID Properties
A transaction is a unit of program execution that accesses and possibly
updates various data items. To preserve the integrity of data the database
system must ensure:
▪ Atomicity. Either all operations of the transaction are properly reflected in
the database or none are.
▪ Consistency. Execution of a transaction in isolation preserves the
consistency of the database.
▪ Isolation. Although multiple transactions may execute concurrently, each
transaction must be unaware of other concurrently executing transactions.
Intermediate transaction results must be hidden from other concurrently
executed transactions.
• That is, for every pair of transactions Ti and Tj, it appears to Ti that either
Tj, finished execution before Ti started, or Tj started execution after Ti
finished.
▪ Durability. After a transaction completes successfully, the changes it has
made to the database persist, even if there are system failures.

Database System Concepts - 7th Edition 17.10 ©Silberschatz, Korth and Sudarshan
 ACID Properties cont.

▪ Ensuring atomicity is the responsibility of the database system itself; specifically, it

is handled by a component called the transaction-management component,
supported by the recovery-manager.
▪ Ensuring consistency for an individual transaction is the responsibility of the
application programmer who codes the transaction. This task may be facilitated
by automatic testing of integrity constraints.
▪ Ensuring the isolation property is the responsibility of a component of the
database system called the concurrency-control component.
▪ Ensuring durability is the responsibility of a component of the database system
called the recovery-manager.

Database System Concepts - 7th Edition 17.11 ©Silberschatz, Korth and Sudarshan
 Transaction - Terminologies

▪ Without failures, all transactions complete successfully. However, a transaction

may not always complete its execution successfully. Such a transaction is
termed aborted.
▪ If we are to ensure the atomicity property, an aborted transaction must have
no effect on the state of the database.
▪ Thus, any changes that the aborted transaction made to the database must be
undone. Once the changes caused by an aborted transaction have been
undone, we say that the transaction has been rolled back.
▪ A transaction that completes its execution successfully is said to be
committed. A committed transaction that has performed updates transforms
the database into a new consistent state, which must persist even if there is a
system failure.
▪ Once a transaction has committed, we cannot undo its effects by aborting it.
The only way to undo the effects of a committed transaction is to execute a
compensating transaction.

Database System Concepts - 7th Edition 17.12 ©Silberschatz, Korth and Sudarshan
 Transaction State

▪ Active – the initial state; the transaction stays in this state while it is
executing
▪ Partially committed – after the final statement has been executed.
▪ Failed -- after the discovery that normal execution can no longer proceed.
▪ Aborted – after the transaction has been rolled back and the database
restored to its state prior to the start of the transaction.
▪ Two options after it has been aborted:
• Restart the transaction
▪ Can be done only if no internal logical error
• Kill the transaction
▪ Committed – after successful completion.

Database System Concepts - 7th Edition 17.13 ©Silberschatz, Korth and Sudarshan
 Transaction State cont

A transaction must be in one of the State Diagram

following states:
Active: the initial state; the
transaction stays in this state while it
is executing.
Partially committed: after the final
statement has been executed.
Failed: after the discovery that
normal execution can no longer
proceed.
Aborted: after the transaction has
been rolled back and the database
has been restored to its state prior to
the start of the transaction.
Committed: after successful
completion.
A transaction is said to have terminated
if has either committed or aborted.

Database System Concepts - 7th Edition 17.14 ©Silberschatz, Korth and Sudarshan
 Implementation of Atomicity and Durability

▪ The recovery-management component of a database system can support

atomicity and durability by a variety of schemes as follows:
• shadow copy scheme: This is a simple, but extremely inefficient scheme,
which is based on making copies of the database, called shadow copies.
• This scheme assumes that only one transaction is active at a time. The
scheme also assumes that the database is simply a file on disk.
• A pointer called db-pointer is maintained on disk, and, it points to the current
copy of the database.

Database System Concepts - 7th Edition 17.15 ©Silberschatz, Korth and Sudarshan
 Shadow-copy technique for atomicity and durability
A transaction that wants to update the
database first creates a complete copy
of the database.
All updates are done on the new
database copy, leaving the original
copy, the shadow copy, untouched.
If at any point the transaction has to be
aborted, the system merely deletes the
new copy. The old copy of the
database has not been affected.
If the transaction completes, it is
committed as follows:
First, the operating system is asked to
make sure that all pages of the new
copy of the database have been written
out to disk.
After the operating system has written
all the pages to disk, the database
system updates the pointer db-pointer
to point to the new copy of the
database; the new copy then becomes
the current copy of the database.
The old copy of the database is then
Database System Concepts - 7th Edition 17.16
deleted. ©Silberschatz, Korth and Sudarshan
 Concurrent Executions

▪ One major disadvantage of the shadow copy scheme implementation is that it

does not allow for concurrent execution of transactions.
▪ It is also deficient; if for instance, a large database is to be copied each time
there’s a transaction.
▪ Transaction-processing systems usually allow multiple transactions to run
concurrently.
▪ However, allowing multiple transactions to update data concurrently causes
several complications with consistency of the data, as we saw earlier.
▪ Ensuring consistency in spite of concurrent execution of transactions requires
extra work; it is far easier to insist that transactions run serially—that is, one at a
time, each starting only after the previous one has completed.

Database System Concepts - 7th Edition 17.17 ©Silberschatz, Korth and Sudarshan
 Reasons for allowing concurrency

▪ There are two good reasons for allowing concurrency as follows:

• Improved throughput and resource utilization. Consider transactions
involving I/O activity and CPU usage, these two tasks can be done in parallel
in order to increase the number of transaction done per unit time and efficient
utilization of CPU resource, since they spend little time idle.
• Reduced waiting time. Quite often, there is a mix of transactions, some big
tasks, while others are small, therefore, short tasks should not be made to
wait too long for the big tasks to finish before it starts. It is better to make them
run concurrently, by sharing CPU time cycles and disk accesses. This would
increase the average response time: the average time for a transaction to be
completed after it has been submitted.

Database System Concepts - 7th Edition 17.18 ©Silberschatz, Korth and Sudarshan
 Concurrent Executions cont.

▪ Multiple transactions are allowed to run concurrently in the system.

Advantages are:
• Increased processor and disk utilization, leading to better
transaction throughput
▪ E.g., one transaction can be using the CPU while another is
reading from or writing to the disk
• Reduced average response time for transactions: short transactions
need not wait behind long ones.
▪ Concurrency control schemes – mechanisms to achieve isolation
• That is, to control the interaction among the concurrent transactions in
order to prevent them from destroying the consistency of the database
▪ When several transactions run concurrently, database consistency can be
destroyed despite the correctness of each individual transaction.
▪ Let us study some transaction scheduling schemes that guarantees
database consistency.

Database System Concepts - 7th Edition 17.19 ©Silberschatz, Korth and Sudarshan
 Schedules

▪ Schedule – a sequences of instructions that specify the chronological

order in which instructions of concurrent transactions are executed
• A schedule for a set of transactions must consist of all instructions of
those transactions
• Must preserve the order in which the instructions appear in each
individual transaction.
▪ A transaction that successfully completes its execution will have a commit
instructions as the last statement
• By default transaction is assumed to execute commit instruction as its
last step
▪ A transaction that fails to successfully complete its execution will have an
abort instruction as the last statement

Database System Concepts - 7th Edition 17.20 ©Silberschatz, Korth and Sudarshan
 Schedule 1

▪ Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from
A to B.
▪ A serial schedule in which T1 is followed by T2 :

Database System Concepts - 7th Edition 17.21 ©Silberschatz, Korth and Sudarshan
 Schedule 2

▪ A serial schedule where T2 is followed by T1

Database System Concepts - 7th Edition 17.22 ©Silberschatz, Korth and Sudarshan
 Schedules 1 and 2

▪ T1 transfer $50 from A to B, and

▪ T2 transfer 10% of the balance from A to B.
▪ Schedule 1: A serial schedule in which T1 is followed by T2 :
▪ Schedule 2: Another serial schedule where T2 is followed by T1

Database System Concepts - 7th Edition 17.23 ©Silberschatz, Korth and Sudarshan
 ▪ When the database system executes several transactions concurrently, the
corresponding schedule no longer needs to be serial.
▪ If two transactions are running concurrently, the operating system may execute
one transaction for a little while, then perform a context switch, execute the
second transaction for some time, and then switch back to the first transaction for
some time, and so on.
▪ With multiple transactions, the CPU time is shared among all the transactions.

▪ However, several execution sequences are possible, since the various instructions
from both transactions may now be interleaved.
▪ In general, it is not possible to predict exactly how many instructions of a
transaction will be executed before the CPU switches to another transaction.

Database System Concepts - 7th Edition 17.24 ©Silberschatz, Korth and Sudarshan
 Schedule 3 – Concurrent Schedule

▪ Let T1 and T2 be the transactions defined previously. The following schedule

is not a serial schedule, but it is equivalent to Schedule 1

▪ In Schedules 1, 2 and 3, the sum A + B is preserved.

Database System Concepts - 7th Edition 17.25 ©Silberschatz, Korth and Sudarshan
 Schedule 4

▪ Not all concurrent executions result in a

correct state. To illustrate, consider
schedule 4.
• Schedule 4 does not preserve the value
of (A + B ).
▪ After the execution of this schedule, we
arrive at a state where the final values of
accounts A and B are $950 and $2100,
respectively.
▪ This final state is an inconsistent state,
since we have gained $50 in the process of
the concurrent execution.
▪ It is the job of the database system to
ensure that any schedule that gets
executed will leave the database in a
consistent state.
▪ The concurrency-control component of
the database system carries out this task.

Database System Concepts - 7th Edition 17.26 ©Silberschatz, Korth and Sudarshan
 SERIALIZABILITY

Database System Concepts - 7th Edition 17.27 ©Silberschatz, Korth and Sudarshan
 Introduction

▪ 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, are possible.
▪ It is the job of the database system to ensure that any schedule that gets executed
will leave the database in a consistent state. The concurrency-control
component 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.
▪ In this unit, we shall illustrate concurrent execution of transactions with some
examples to explain how a database could be in an inconsistent state, if not
controlled.
▪ You will also be introduced to some new concepts of how to schedule transactions
to ensure database consistency as well as how to initiate a transaction using SQL.

Database System Concepts - 7th Edition 17.28 ©Silberschatz, Korth and Sudarshan
 Serializability

▪ When two or more transactions are executed concurrently on a database, their

effect should be the same as if they had executed serially.
▪ It is therefore important that we know which schedule will lead to database
consistency and which will not.
▪ Most schedule schemes lead to the concept of Conflict serializability and View
serializability as discussed below.

Database System Concepts - 7th Edition 17.29 ©Silberschatz, Korth and Sudarshan
 Serializability

▪ Basic Assumption – Each transaction preserves database consistency.

▪ Thus, serial execution of a set of transactions preserves database
consistency.
▪ A (possibly concurrent) schedule is serializable if it is equivalent to a
serial schedule. Different forms of schedule equivalence give rise to the
notions of:
1. Conflict serializability
2. View serializability

Database System Concepts - 7th Edition 17.30 ©Silberschatz, Korth and Sudarshan
 Simplified view of transactions

▪ We ignore operations other than read and write instructions

▪ We assume that transactions may perform arbitrary computations on data in
local buffers in between reads and writes.
▪ Our simplified schedules consist of only read and write instructions.

Database System Concepts - 7th Edition 17.31 ©Silberschatz, Korth and Sudarshan
 Conflict Serializability
• Consider a schedule, S with two consecutive instructions Ii and Ij in
transactions Ti and Tj respectively (i  j). If Ii and Ij refer to different data items,
then we can swap Ii and Ij without affecting the results of any instructions in the
schedule. However, if Ii and Ij refer to the same data item Q, then the order of the
two steps may matter. For the moment, let’s deal with only Read and Write
instructions since they are the only significant operations of a transaction, from a
scheduling point of view
• Now, the four cases that may arise are:
i. Ii = read (Q), Ij = read (Q). The order of instructions Ii and Ij does not matter, since
the two instructions both read the same value of Q, from two different transactions
Ti and Ti.
ii. Ii = read (Q), Ij = write (Q). If Ii comes before Ij, then Ti does not read the value of Q
that is written by Tj in instruction Ij. If Ij comes before Ii then Ti read the value of Q
written by Tj. Thus the order Ii and Ij matters.
iii. Ii = write (Q), Ij = read (Q). For the same reason as in ii) above, the order of the two
transactions matter.
iv. Ii = write (Q), Ij = write (Q). Since they both are writing, the order of the two
transactions matter and the next read(Q) instruction will have the value of the last
write instruction.
 Conflicting Instructions

▪ Instructions li and lj of transactions Ti and Tj respectively, conflict if and

only if there exists some item Q accessed by both li and lj, and at least one
of these instructions wrote Q.
1. li = read(Q), lj = read(Q). li and lj don’t conflict.
2. li = read(Q), lj = write(Q). They conflict.
3. li = write(Q), lj = read(Q). They conflict
4. li = write(Q), lj = write(Q). They conflict
▪ Intuitively, a conflict between li and lj forces a (logical) temporal order
between them.
▪ If li and lj are consecutive in a schedule and they do not conflict, their
results would remain the same even if they had been interchanged in the
schedule.

Database System Concepts - 7th Edition 17.33 ©Silberschatz, Korth and Sudarshan
 Conflict Serializability cont

We therefore say that the execution of two

instructions conflict if they are operations
by different transactions on the same data
item, and at least one of these instructions is
a write operation.
To illustrate the concept of conflicting
instructions, we consider schedule 3, in the
previous lesson. The write(A) instruction of
T1 conflicts with the read(A) instruction of T2.
However, the write(A) instruction of T2 does
not conflict with the read(B) instruction of T1,
because the two instructions access
different data items.

Schedule 3

Database System Concepts - 7th Edition 17.34 ©Silberschatz, Korth and Sudarshan
 Conflict Serializability

▪ If a schedule S can be transformed into a schedule S’ by a series of swaps

of non-conflicting instructions, we say that S and S’ are conflict
equivalent.
▪ We say that a schedule S is conflict serializable if it is conflict equivalent
to a serial schedule.
▪ In our previous examples, schedule 1 is not conflict equivalent to schedule
2. However, schedule 1 is conflict equivalent to schedule 3, because the
read(B) and write(B) instruction of T1 can be swapped with the read(A) and
write(A) instruction of T2. Schedule 2 Schedule 3
Schedule 1

Database System Concepts - 7th Edition 17.35 ©Silberschatz, Korth and Sudarshan
 Conflict Serializability (Cont.)

▪ Schedule 3 can be transformed into Schedule 6, a serial schedule where T2

follows T1, by series of swaps of non-conflicting instructions. Therefore
Schedule 3 is conflict serializable.

Schedule 3 Schedule 6

Note: It is however possible to have two schedules that produce the same
outcome, but that are not conflict equivalent.

Database System Concepts - 7th Edition 17.36 ©Silberschatz, Korth and Sudarshan
 Conflict Serializability (Cont.)

▪ Example of a schedule that is not conflict serializable:

▪ We are unable to swap instructions in the above schedule to obtain either

the serial schedule < T3, T4 >, or the serial schedule < T4, T3 >.

Database System Concepts - 7th Edition 17.37 ©Silberschatz, Korth and Sudarshan
 View Serializability

▪ It is a form of equivalence that is less stringent than conflict equivalence, but that,
like conflict equivalence, is based on only the read and write operations of
transactions.
▪ Consider two schedules S and S’, where the same set of transactions participates
in both schedules. The schedules S and S’ are said to be view equivalent if three
conditions are met:
1. For each data item Q, if transaction Ti reads the initial value of Q in
schedule S, then transaction Ti must, in schedule S’, also read the initial
value of Q.
2. For each data item Q, if transaction Ti executes read(Q) in schedule S, and
if that value was produced by a write(Q) operation executed by transaction
Tj , then the read(Q) operation of transaction Ti must, in schedule S’, also
read the value of Q that was produced by the same write(Q) operation of
transaction Tj.
3. For each data item Q, the transaction (if any) that performs the final
write(Q) operation in schedule S must perform the final write(Q) operation in
schedule S’.

Database System Concepts - 7th Edition 17.38 ©Silberschatz, Korth and Sudarshan
 View Serializability

▪ Let S and S’ be two schedules with the same set of transactions. S and S’
are view equivalent if the following three conditions are met, for each data
item Q,
1. If in schedule S, transaction Ti reads the initial value of Q, then in
schedule S’ also transaction Ti must read the initial value of Q.
2. If in schedule S transaction Ti executes read(Q), and that value was
produced by transaction Tj (if any), then in schedule S’ also
transaction Ti must read the value of Q that was produced by the
same write(Q) operation of transaction Tj .
3. The transaction (if any) that performs the final write(Q) operation in
schedule S must also perform the final write(Q) operation in schedule S’.
▪ As can be seen, view equivalence is also based purely on reads and writes
alone.
▪ Conditions 1 and 2 above ensure that each transaction reads the same
values in both schedules and, therefore, performs the same computation.
▪ Condition 3, coupled with conditions 1 and 2, ensures that both schedules
result in the same final system state.

Database System Concepts - 7th Edition 17.39 ©Silberschatz, Korth and Sudarshan
 View Serializability cont.

▪ The concept of view equivalence leads to the concept of view serializability.

We say that a schedule S is view serializable if it is view equivalent to a
serial schedule.
▪ In our previous examples, schedule 1 is not view equivalent to schedule 2,
since, in schedule 1, the value of account A read by transaction T2 was
produced by T1, whereas this case does not hold in schedule 2.
▪ However, schedule 1 is view equivalent to schedule 3, because the values
of account A and B read by transaction T2 were produced by T1 in both
schedules. Schedule 2 Schedule 3
Schedule 1

Database System Concepts - 7th Edition 17.40 ©Silberschatz, Korth and Sudarshan
 View Serializability (Cont.)

▪ A schedule S is view serializable if it is view equivalent to a serial

schedule.
▪ Every conflict serializable schedule is also view serializable, but there are
view serializable schedules that are not conflict serializable.
▪ Below is a schedule which is view-serializable but not conflict serializable.

▪ Every view serializable schedule that is not conflict serializable has blind
writes.
▪ Transactions that perform write operations without having performed a
read operation are called blind writes.
▪ Blind writes appear in any view-serializable schedule that is not conflict
serializable.

Database System Concepts - 7th Edition 17.41 ©Silberschatz, Korth and Sudarshan
 RECOVERABILITY

Database System Concepts - 7th Edition 17.43 ©Silberschatz, Korth and Sudarshan
 Recoverability

▪ So far, we have studied what schedules are acceptable from the viewpoint of
consistency of the database, assuming implicitly that there are no transaction
failures.
▪ We now address the effect of transaction failures during concurrent execution.
▪ If a transaction Ti fails, for whatever reason, we need to undo the effect of this
transaction to ensure the atomicity property of the transaction.
▪ In a system that allows concurrent execution, it is necessary also to ensure that
any transaction Tj that is dependent on Ti (that is, Tj has read data written by Ti )
is also aborted.
▪ To achieve this, we need to place restrictions on the type of schedules permitted
in the system. Therefore, we need to address the issue of what schedules are
acceptable from the viewpoint of recovery from transaction failure.

Database System Concepts - 7th Edition 17.44 ©Silberschatz, Korth and Sudarshan
 Recoverable Schedules

Need to address the effect of transaction failures on concurrently

running transactions.
▪ Recoverable schedule — if a transaction Tj reads a data item previously
written by a transaction Ti , then the commit operation of Ti appears before
the commit operation of Tj.
▪ The following schedule (Schedule 11) is not recoverable
A dirty read occurs when a
transaction reads a
database object that has
been modified by another
not-yet-committed
transaction.

▪ Now suppose that T8 fails before it commits. Since T9 has read the value of
data item A written by T8, we must abort T9 to ensure transaction atomicity.
▪ However, T9 has already committed and cannot be aborted. Thus, we have
a situation where it is impossible to recover correctly from the failure of T8.
▪ This is an example of a non-recoverable schedule, which should not be
allowed. Most database system require that all schedules be recoverable.

Database System Concepts - 7th Edition 17.45 ©Silberschatz, Korth and Sudarshan
 Cascading Rollbacks

▪ Even if a schedule is recoverable, to recover

correctly from the failure of a transaction Ti, we
may have to roll back several transactions. Such
situations occur if transactions have read data
written by Ti. For example:
• If T10 fails, T10 must be rolled back. Since T11
is dependent on T10, T11 must be rolled back.
Since T12 is dependent on T11, T12 must be
rolled back.
▪ This phenomenon, in which a single transaction
failure leads to a series of transaction rollbacks, is
called cascading rollback.

Database System Concepts - 7th Edition 17.46 ©Silberschatz, Korth and Sudarshan
 Cascading Rollbacks

▪ Cascading rollback – a single transaction failure

leads to a series of transaction rollbacks. Consider
the following schedule where none of the transactions
has yet committed (so the schedule is recoverable)
• If T10 fails, T11 and T12 must also be rolled back.
• Can lead to the undoing of a significant amount of
work
▪ Cascading rollback is undesirable, since it leads to the
undoing of a significant amount of work. It is desirable
to restrict the schedules to those where cascading
rollbacks cannot occur. Such schedules are called
cascadeless schedules.
▪ A cascadeless schedule is one where, for each pair
of transactions Ti and Tj such that Tj reads a data item
previously written by Ti, the commit operation of Ti
appears before the read operation of Tj . It is easy to
verify that every cascadeless schedule is also
recoverable.

Database System Concepts - 7th Edition 17.47 ©Silberschatz, Korth and Sudarshan
 Cascadeless Schedules

▪ Cascadeless schedules — cascading rollbacks cannot occur;

• For each pair of transactions Ti and Tj such that Tj reads a data item
previously written by Ti, the commit operation of Ti appears before the
read operation of Tj.
▪ Every Cascadeless schedule is also recoverable
▪ It is desirable to restrict the schedules to those that are cascadeless

Database System Concepts - 7th Edition 17.48 ©Silberschatz, Korth and Sudarshan
 Concurrency Control

▪ A database must provide a mechanism that will ensure that all possible
schedules are
• either conflict or view serializable, and
• are recoverable and preferably cascadeless
▪ A policy in which only one transaction can execute at a time generates
serial schedules, but provides a poor degree of concurrency
• Are serial schedules recoverable/cascadeless?
▪ Testing a schedule for serializability after it has executed is a little too late!
▪ Goal – to develop concurrency control protocols that will assure
serializability.

Database System Concepts - 7th Edition 17.49 ©Silberschatz, Korth and Sudarshan
 Levels of Consistency in SQL-92

▪ Serializable — default
▪ Repeatable read — only committed records to be read.
• Repeated reads of same record must return same value.
• However, a transaction may not be serializable – it may find some
records inserted by a transaction but not find others.
▪ Read committed — only committed records can be read.
• Successive reads of record may return different (but committed)
values.
▪ Read uncommitted — even uncommitted records may be read.

Database System Concepts - 7th Edition 17.52 ©Silberschatz, Korth and Sudarshan
 Transaction Definition in SQL

▪ In SQL, a transaction begins implicitly.

▪ A transaction in SQL ends by:
• Commit work commits current transaction and begins a new one.
• Rollback work causes current transaction to abort.
▪ The keyword work is optional in both the statements.
▪ The Commit statement is used in SQL to signal successful end of all
updates in a transaction and it tells the DBMS to save all the changes to the
database and terminate the current transaction.
▪ On the other hand, Rollback statement is used in SQL to abort all updates
within the current transaction and instructs the database to revert to its
original state before the transaction commenced.
▪ If a program terminates without either of these commands, the updates are
either committed or rolled back (which of the two happens is not specified by
the standard and depends on the implementation).
▪ The standard also specifies that the system must ensure both serializability
and freedom from cascading rollback. The definition of serializability used by
the standard is that a schedule must have the same effect as would some
serial schedule. Thus, conflict and view serializability are both acceptable.
Database System Concepts - 7th Edition 17.54 ©Silberschatz, Korth and Sudarshan
 Transaction Definition in SQL

▪ In almost all database systems, by default, every SQL statement also

commits implicitly if it executes successfully
• Implicit commit can be turned off by a database directive
▪ E.g., in JDBC -- connection.setAutoCommit(false);
▪ Isolation level can be set at database level
▪ Isolation level can be changed at start of transaction
▪ E.g. In SQL set transaction isolation level serializable
▪ E.g. in JDBC -- connection.setTransactionIsolation(
Connection.TRANSACTION_SERIALIZABLE)

Database System Concepts - 7th Edition 17.55 ©Silberschatz, Korth and Sudarshan
 Transactions as SQL Statements
▪ E.g., Transaction 1:
select ID, name from instructor where salary > 90000
▪ E.g., Transaction 2:
insert into instructor values ('11111', 'James', 'Marketing', 100000)
▪ Suppose
• T1 starts, finds tuples salary > 90000 using index and locks them
• And then T2 executes.
• Do T1 and T2 conflict? Does tuple level locking detect the conflict?
• Instance of the phantom phenomenon
▪ Also consider T3 below, with Wu’s salary = 90000
update instructor
set salary = salary * 1.1
where name = 'Wu’
▪ Key idea: Detect “predicate” conflicts, and use some form of “predicate
locking”

Database System Concepts - 7th Edition 17.57 ©Silberschatz, Korth and Sudarshan
 Example

▪ Begin transaction
▪ insert into orders values (“ÁCB234”, ’29-Jan-2022”, “S113”);
▪ insert into orders values (“ÁCB234”, ’28-Jan-2022”, “S176”);
▪ ….
▪ update stock;
▪ set stock_qty = stock_qty - 25
▪ where prdtcode = “S560”;
▪ update stock
▪ set stock_qty = stock_qty -25
▪ where prdtcode = “K552”
▪ ….
▪ Commit
▪ End transaction

Database System Concepts - 7th Edition 17.58 ©Silberschatz, Korth and Sudarshan
 Further Reading
Chapter 17

Database System Concepts - 7th Edition 17.59 ©Silberschatz, Korth and Sudarshan