TRANSACTIONS

UNIT -IV

UNIT - IV
Transaction

• A transaction is a unit of program execution that

accesses and possibly updates various data items.

• It is a collections of operations that form a single

logical unit of work

• A transaction is delimited by statements (or

function calls) of the form begin transaction
and end transaction. The transaction consists
of all operations executed between the begin
transaction and end transaction.
Transaction States

• Active
• Partially Committed
• Committed
• Failed
• Aborted
State diagram of a Transaction
Transaction 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.
■
Transaction States

■ A transaction is said to have terminated if it has

either committed or aborted.

Transaction States

• A transaction enters the failed state after the

system determines that the transaction can
no longer proceed with its normal execution
(e.g., 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:
■ Restart the transaction
■ Kill the transaction
Transaction States
■ Restart the transaction
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.

■ 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.
ACID Properties

• Atomicity

• Consistency

• Isolation

• Durability
ACID Properties

■ Atomicity
Either all operations of the transaction are reflected
properly in the database, or none are.

■ Consistency
Execution of a transaction in isolation(i.e. with no other
transaction executing concurrently) preserves the
consistency
of the database.
ACID Properties
■ Isolation
Even though multiple transactions may execute
concurrently, the system guarantees that, 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.
Operations

• read(X)

Read operation is used to read the value of X from the

database and stores it in a buffer in main memory.

• write(X)

Write operation is used to write the value back to the

database from the buffer.

Transaction model
Example:

Bank application consisting of several accounts and a

set of transactions that access and update those accounts.

Transactions access data using two operations:

■ read(X), which transfers the data item X from the database to a
variable, also called X, in a buffer in main memory belonging to the
transaction that executed the read operation.
■ write(X), which transfers the value in the variable X in the main-
memory buffer of the transaction that executed the write to the data
item X in the database.
Transaction model

Let Ti be a transaction that transfers $50 from account A to

account B. This transaction can be defined as:
Transaction model
Consistency:
The consistency requirement here is that the sum of A and
B be unchanged by the execution of the transaction.

Atomicity:
• Suppose that, just before the execution of transaction Ti, the
values of accounts A and B are $1000 and $2000,
respectively. Now suppose that, during the execution of
transaction Ti, a failure occurs that prevents Ti from
completing its execution successfully.
• Further, suppose that the failure happened after the write(A)
operation but before the write(B) operation.
Transaction model

Atomicity:
• In this case, the values of accounts A and B reflected in the
database are $950 and $2000.
• The system destroyed $50 as a result of this failure. In
particular, we note that the sum A + B is no longer
preserved.

If the atomicity property is present, all actions of the

transaction are reflected in the database, or none are.
Transaction model
Durability:
The durability property guarantees that, once a transaction
completes successfully, all the updates that it carried out on the
database persist, even if there is a system failure after the transaction
completes execution.

Isolation:
Even if the consistency and atomicity properties are ensured for each
transaction, if several transactions are executed concurrently, their
operations may interleave in some undesirable way, resulting in an
inconsistent state.
A way to avoid the problem of concurrently executing transactions is
to execute transactions serially—that is, one after the other.
Transaction Recovery

• COMMIT
Committing a transaction means making
permanent changes
performed by the SQL statements within
the transaction.
• Write-ahead log rule
write-ahead logging (WAL) is a technique
for providing
atomicity and durability in database systems. The
Transaction Recovery

• SAVEPOINT
A savepoint is a way of implementing sub-
transactions (also known as nested transactions)
within a relational database management system by
indicating a point within a transaction that can be
"rolled back to" without affecting any work done in
the transaction before the savepoint was created.
• ROLLBACK
It is used to undo all the changes made on the
current transaction
Concurrency

▪ Transaction-processing systems usually allow multiple

transactions to run concurrently.
▪ Allowing multiple transactions to update data
concurrently causes several complications with
consistency of the data

Reasons for allowing concurrency

• Improved throughput and resource utilization
• Reduced waiting time
Concurrency Control

Several problems can occur when concurrent

transactions execute in an uncontrolled manner.

Consider the following transactions T1 and T2.

Concurrency Control

Transaction1 Transaction 2
Concurrency Control

1. The Lost Update Problem

Concurrency Control
1. The Lost Update Problem
This problem occurs when two transactions that access the
same database items have their operations interleaved in a way
that makes the value of some database items incorrect.

• Suppose that transactions T1 and T2 are submitted at

approximately the same time, and suppose that their
operations are interleaved as shown in Figure.
• Then the final value of item X is incorrect because T2 reads
the value of X before T1 changes it in the database, and hence
the updated value resulting from T1 is lost.
Concurrency Control

1. The Lost Update Problem

if X = 80 at the start,
N = 5 and M = 4
the final result should
be
X = 79

However, in the
interleaving of
operations ,it is X =
84
Concurrency Control

2. The Temporary Update or Dirty Read Problem

This problem occurs when one transaction updates a database
item and then the transaction fails for some reason. Meanwhile,
the updated item is accessed (read) by another transaction before
it is changed back (or rolled back) to its original value.
Concurrency Control

2. The Temporary Update or Dirty Read Problem

T1 Fails
Concurrency Control
2. The Temporary Update or Dirty Read Problem
• T1 updates item X and then fails before completion, so the system
must roll back X to its original value.
• Before it can do so, however, transaction T2 reads the temporary
value of X, which will not be recorded permanently in the database
because of the failure of T1.
• The value of item X that is read by T2 is called dirty data because it
has been created by a transaction that has not completed and
committed yet; hence, this problem is also known as the dirty read
problem.
Concurrency Control
3. The Incorrect Summary Problem
If one transaction is calculating an aggregate
summary function on a number of database items while
other transactions are updating some of these items, the
aggregate function may calculate some values before they
are updated and others after they are updated.
Concurrency Control

3. The Incorrect Summary Problem

If X = 100, A=50, Y=30
N = 20
the final result should be
sum = 50+80+50
=180
However,it is sum = 50+80+30
= 160
Concurrency Control
4.The Unrepeatable Read Problem
Unrepeatable read may occur when a transaction T
reads the same item twice and the item is changed by another
transaction T′ between the two reads.
Concurrency Control

4.The Unrepeatable Read Problem

T1 T2
Read(x)
Read(x)
Write(x)
Read(x)
SCHEDULE

Chronological order of execution of operations

from various transactions
SERIALIZABILITY

• Serializability is a concurrency scheme.

• It ensures that a schedule for executing
concurrent transactions is equivalent to one
that executes the transactions serially in
some order.
• It assumes that all accesses to the database
are done using read and write operations.
SERIALIZABILITY

Serial & Non-serial schedule

• a schedule S is serial if, for every transaction T participating
in the schedule, all the operations of T are executed
consecutively in the schedule ( one transaction after another)

• otherwise, the schedule is called non serial

SERIALIZABILITY

Serial Schedule

a serial schedule in which T2 is followed by T1

CONFLICT SERIALIZABILITY
Consider a Schedule S with two consecutive
instructions I and J of Transactions Ti and Tj .

■ If I and J refer to different data items, then we can

swap I and J without affecting the results of any
instruction in the schedule.
■ However, if I and J refer to the same data item Q, then
the order of the two steps may matter.
CONFLICT SERIALIZABILITY
Four cases, need to consider:
1. I = read(Q), J = read(Q). The order of I and J does not
matter, since the same value of Q is read by Ti and Tj,
regardless of the order.
2. I = read(Q), J = write(Q). If I comes before J, then Ti does
not read the value of Q that is written by Tj in instruction J.
If J comes before I, then Ti reads the value of Q that is
written by Tj. Thus, the order of I and J matters.
3. I = write(Q), J = read(Q). The order of I and J matters
for reasons similar to those of the previous case.
CONFLICT SERIALIZABILITY
4. I = write(Q), J = write(Q). Since both instructions are
write operations, the order of these instructions does not
affect either Ti or Tj.
• However, the value obtained by the next read(Q)
instruction of S is affected, since the result of only the
latter of the two write instructions is preserved in the
database.
• If there is no other write(Q) instruction after I and J in
S, then the order of I and J directly affects the final
value of Q in the database state that results from
CONFLICT SERIALIZABILITY

2 operations in a schedule are conflict, if they

satisfy the following conditions

• they belongs to different transactions

• they access the same data item X
• at least one of the operation is Write
CONFLICT SERIALIZABILITY

Consider the following schedule S with

transactions T1 and T2
CONFLICT SERIALIZABILITY

In this schedule,
• 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.
CONFLICT SERIALIZABILITY
• Since the write(A) instruction of T2 in schedule S does not
conflict with the read(B) instruction of T1, we can swap
these instructions to generate an equivalent schedule
CONFLICT SERIALIZABILITY

We continue to swap nonconflicting instructions:

• Swap the read(B) instruction of T1 with the read(A)
instruction of T2.

• Swap the write(B) instruction of T1 with the write(A)

instruction of T2.

• Swap the write(B) instruction of T1 with the read(A)

instruction of T2.
CONFLICT SERIALIZABILITY

Final Schedule S’
 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.

Schedule S is conflict serializable if it is conflict

equivalent to a serial schedule S’.
 CONFLICT SERIALIZABILITY

Method for determining the conflict serializability of a schedule

■ Consider a schedule S.
■ We construct a directed graph, called a precedence graph, from
S.
■ This graph consists of a pair G = (V, E), where V is a set of
vertices and E is a set of edges.
■ The set of vertices consists of all the transactions participating in
the schedule.
 CONFLICT SERIALIZABILITY

Method for determining the conflict serializability of

a schedule
■ The set of edges consists of all edges Ti → 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).
 CONFLICT SERIALIZABILITY

Method for determining the conflict serializability of a

schedule
• If an edge Ti → Tj exists in the precedence graph, then, in
any serial schedule S′ equivalent to S, Ti must appear
before Tj.
• 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.
CONFLICT SERIALIZABILITY

All the instructions of T1 are executed before

the first instruction of T2 is executed.

Edge : T1 → T2

Precedence graph :

Graph has no cycles. So the schedule is

conflict serializable
CONFLICT SERIALIZABILITY

T1 executes read(A) before T2 executes write(A)

T2 executes read(B) before T1 executes write(B)

Edge : T1 → T2
T2 → T1

Precedence graph :

Graph has a cycles. So the schedule is not

conflict serializable