Transactions

Book Referred: Chapter 14, Transactions,

Korth, 6th Edition

April 21, 2025

Overview
Transaction Concept
Transaction State
Concurrent Executions
Serializability
Recoverability
Implementation of Isolation
Transaction Definition in SQL
Testing for Serializability

April 21, 2025

Transaction Concept
 A transaction is a unit of program execution
that accesses and possibly updates various
data items.
 A transaction must see a consistent database.
 During transaction execution the database may
be temporarily inconsistent.
 When the transaction completes successfully (is
committed), the database must be consistent.
 After a transaction commits, the changes it has
made to the database persist, even if there are
system failures.
 Multiple transactions can execute in parallel.
 Two main issues to deal with:
 Failures of various kinds, such as hardware failures
and system crashes
 Concurrent execution of multiple transactions

April 21, 2025

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 Either
 Atomicity. ensure:
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 T and T , it
i j
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.
April 21, 2025
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, the system should
ensure that its updates are not reflected in the
database, else an inconsistency will result.
Consistency requirement – the sum of A and B
is unchanged by the execution of the transaction.

April 21, 2025

Example of Fund Transfer
(Cont…)
Isolation requirement — if between steps 3
and 6, another transaction 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).
 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.
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 despite failures.

April 21, 2025

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:- Transaction which has not successfully
completed its transaction. 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.
 Committed:- After successful completion.

April 21, 2025

Transaction State
 A transaction starts in the active state.
 When it finishes its final statement, it enters the partially
committed state. At this point, the transaction has completed
its execution, but it is still possible that it may have to be
aborted, since the actual output may still be temporarily
residing in main memory, and thus a hardware failure may
preclude its successful completion.
 The database system then writes out enough information to
disk that, even in the event of a failure, the updates
performed by the transaction can be re-created when the
system restarts after the failure.
 When the last of this information is written out, the
transaction enters the committed state.
 A transaction enters the failed state after the system
determines that the transaction can no longer proceed with its
normal execution (for example, because of hardware or logical
errors). Such a transaction must be rolled back. Then, it enters
the aborted state. At this point, the system has two options:
April 21, 2025
Transaction State
 It can restart the transaction, but only if the
transaction was aborted as a result of some hardware
or software error that was not created through the
internal logic of the transaction. A restarted
transaction is considered to be a new transaction.

 It can kill the transaction. It usually does so because of

some internal logical error that can be corrected only
by rewriting the application program, or because the
input was bad, or because the desired data were not
found in the database.

April 21, 2025

Transaction State (Cont.)

April 21, 2025

Concurrent Executions
 Multiple transactions are allowed to run
concurrently in the system.
 Advantages are:
 Increased processor and disk utilization,
leading to better transaction throughput:
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.
April 21, 2025
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 (will be omitted if it is
obvious)
 A transaction that fails to successfully complete its execution will
have an abort instructions as the last statement (will be omitted if
it is obvious)
 Two Types:
 Serial Schedules: Consist of sequence of instructions from
various transactions, where the instructions belonging to one
single transaction appear together in that schedule.
 Concurrent Schedules: Two transactions running concurrently,
the OS may execute one transaction for a little while, and then
perform context switch, execute the second transaction for Aprilsome
21, 2025
Schedule 1
 Let T transfer $50 from A to B, and T transfer 10%
1 2
of the balance from A to B.
 A serial schedule in which T is followed by T :
1 2

April 21, 2025

 Schedule 2
• A serial schedule where T2 is followed by T1

April 21, 2025

Schedule 3
 Let T and T be the transactions defined previously.
The
1 2
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.

April 21, 2025
Schedule 4
The following concurrent schedule does
not preserve the value of (A + B).

April 21, 2025

Serializability
 Its criterion for correctness for the execution of a given
set of transactions.
 More precisely, a given execution of a set of
transactions is considered to be correct if it is
serializable – i.e. it (interleaved transactions) produces
the same result as some serial execution of the same
transactions, running them one at a time.
 Basic Assumption – Each transaction preserves
database consistency.
 Thus, serial execution of a set of transactions preserves
database consistency.
 Different forms of schedule equivalence give rise to the
notions of:
1. Conflict Serializability
2. View Serializability

April 21, 2025

Conflicting Instructions
 If li and lj refer to different data items, then we can swap li and lj
without affecting the results in any instruction in the schedule.
 However, if li and lj refer to the same data item Q then the order
of the steps may matter.
 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
 We say that li and lj conflict if they are operations by different
transactions on the same data item and at least one of these
instructions is a write operations.
 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.
April 21, 2025
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

April 21, 2025

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 April 21, 2025

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 >.

April 21, 2025

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:
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 that value was
produced by transaction Tj (if any), then
transaction Ti must in schedule S´ also read the
value of Q that was produced by 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´.
April 21, 2025
View Serializability (Cont.)
 A schedule S is view serializable it is view equivalent to a serial
schedule.
 Every conflict serializable schedule is also view 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 T4 and T6 perform write(Q) operations
without having performed a read(Q) operations. It happens only in
schedules which are view serializable but not conflict serializable.
 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.

April 21, 2025

Testing for Serializability
 Consider some schedule of a set of transactions T1, T2, ..., Tn
 Precedence graph — a direct graph where the vertices are the
transactions (names).
 The set of vertices consists of all transactions participating in
that schedule.
 The set of edges consists of all edges T i  Tj for which one of
three conditions holds:
 1. Ti executes write(Q) before Tj executes read(Q).
 2. Ti executes read(Q) before Tj executes write(Q).
 3. Ti executes write(Q) before Tj executes write(Q).
 Example 1

April 21, 2025

 Test for Conflict
Serializability
 If the precedence graph for S has a
cycle, then schedule S is not
conflict serializable. If the graph
contains no cycles, then the
schedule S is conflict serializable.
A serializability order of the
transactions can be obtained
through topological sorting,
which determines a linear order
consistent with the partial order of
the precedence graph.

April 21, 2025

 Recoverability
 Recoverable schedule — if a transaction Tj reads a data
items previously written by a transaction Ti , the commit
operation of Ti appears before the commit operation of Tj.
 The following schedule (Schedule 11) is not recoverable if T9
commits immediately after the read

 If T8 should abort, T9 would have read (and possibly shown

to the user) an inconsistent database state. Hence
database must ensure that schedules are recoverable.

April 21, 2025

Recoverability (Cont.)
 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

 If T fails, T and T must also be rolled back.

10 11 12
 Can lead to the undoing of a significant amount
of work

April 21, 2025

Recoverability (Cont.)
Cascadeless schedules — To avoid
cascading rollback, cascadeless schedules
appears which says that Reads are not
allowed but Overwrite is allowed. But then,
it leads to overwrite conflict.
Every cascadeless schedule is also
recoverable.

April 21, 2025

Recoverability (Cont.)
Strict schedules — To avoid overwrite
conflict, strict schedule says that no read
write is allowed.

April 21, 2025

COMMIT and ROLLBACK
 COMMIT signals the  ROLLBACK signals
successful end of a the unsuccessful end
transaction of a transaction
 Any changes made by  Any changes made by
the transaction should the transaction should
be saved be undone
 These changes are now  It is now as if the
visible to other transaction never
transactions existed

April 21, 2025

End of Chapter

THANK YOU!!!
ANY QUESTIONS???

April 21, 2025