Transaction Concepts 10 Hrs

Transaction Concepts
Agenda
2.1 Transaction, properties of transaction, states of transactions
2.2 Concurrent execution of transactions and conflicting
operations
2.3 Schedules, types of schedules, concept of serializability,
precedence graph for serializability
Transaction
 A sequence of operations that must be treated as an
undivided unit
 Operations read and write
read(x)-Access resource x without modifying it.
write(x)-Modify resource x.
 Transaction must be either committed or aborted
 Example
A transfer between account. Money should be transferred or
withdrawn from account.
ACID Properties
Atomicity:
 We mean that either the entire transaction takes place at once or
doesn’t happen at all. There is no midway i.e. transactions do not
occur partially.
 Each transaction is considered as one unit and either runs to
completion or is not executed at all.
 It involves the following two operations.
Abort: If a transaction aborts, changes made to the database are
not visible.
Commit: If a transaction commits, changes made are visible.
Atomicity is also known as the ‘All or nothing rule’.
Consider the following transaction T consisting of T1 and T2:
Transfer of 100 from account X to account Y.

 If the transaction fails after completion of T1 but before completion

of T2.( say, after write(X) but before write(Y)),
 The amount has been deducted from X but not added to Y. This results in
an inconsistent database state.
 The transaction must be executed in its entirety in order to ensure the
correctness of the database state.
Consistency
 This means that integrity constraints must be maintained so
that the database is consistent before and after the
transaction.
 It refers to the correctness of a database.
 Referring to the example above,
The total amount before and after the transaction must be
maintained.
Total before T occurs = 500 + 200 = 700.
Total after T occurs = 400 + 300 = 700.
Therefore, the database is consistent.
 Inconsistency occurs in case T1 completes but T2 fails. As a
result, T is incomplete.
Isolation

 This property ensures that multiple transactions can occur

concurrently without leading to the inconsistency of the database
state.
 Transactions occur independently without interference.
 Changes occurring in a particular transaction will not be visible to
any other transaction until that particular change in that
transaction is written to memory or has been committed.
 This property ensures that the execution of transactions
concurrently will result in a state that is equivalent to a state
achieved these were executed serially in some order.
 Let X= 500, Y = 500.
Consider two transactions T and T”.

 Suppose T has been executed till Read (Y) and then T’’ starts.
 As a result, interleaving of operations takes place due to which T’’ reads the
correct value of X but the incorrect value of Y and sum computed by
T’’: (X+Y = 50, 000+500=50, 500)
is thus not consistent with the sum at end of the transaction:
T: (X+Y = 50, 000 + 450 = 50, 450).
 This results in database inconsistency, due to a loss of 50 units. Hence,
transactions must take place in isolation and changes should be visible only after
they have been made to the main memory.
Durability

 This property ensures that once the transaction has

completed execution, the updates and modifications to the
database are stored in and written to disk and they persist
even if a system failure occurs.
 These updates now become permanent and are stored in
non-volatile memory.
 The effects of the transaction, thus are never lost.
 States of Transactions

Active − This is the state in which a transaction is being executed. Thus, it

is like the initial state of any given transaction.
Partially Committed − A transaction is in its partially committed state
whenever it executes the final operation.
Failed − In case any check made by a database recovery system fails, then
that transaction is in a failed state. Remember that a failed transaction can
not proceed further.
States of Transactions
 Aborted − In case any check fails, leading the transaction to a
failed state, the recovery manager then rolls all its write
operations back on the database so that it can bring the DB
(database) back to the original state (the state where it actually
was prior to the transaction execution). The transactions in this
state are known to be aborted. A DB recovery module can actually
select one of these two operations after the abortion of a
transaction –
 Re-start
 Kill the transaction
 Committed − We can say that a transaction is committed in case
it actually executes all of its operations successfully. In such a case,
all of its effects are now established permanently on the DB
system.
Concurrent transaction
 Concurrent transaction or execution includes multiple transactions
which are executed concurrently or simultaneously in the system.
 We take ATM machines and we do not use concurrency, then multiple
persons cannot draw money at a time in different places. This is where
we need concurrency.
Advantages
The advantages of the concurrent transactions are as follows :
 Increases throughput which is nothing but number of transactions
completed per unit time.
 It reduces the waiting time.
Disadvantage
 The disadvantage is that the execution of concurrent transactions may
result in inconsistency.
Concurrent transaction
Transaction which is in Transaction which is in
consistent state. inconsistent state.
Concurrency Problems
When multiple transactions execute concurrently in an uncontrolled
or unrestricted manner, then it might lead to several problems.
These problems are commonly referred to as concurrency problems
in a database environment.
The five concurrency problems that can occur in the database are:
 Temporary Update Problem
 Incorrect Summary Problem
 Lost Update Problem
 Unrepeatable Read Problem
 Phantom Read Problem
 Temporary Update Problem

 Temporary update or dirty

read problem occurs when one
transaction updates an item and
fails.
 But the updated item is used by
another transaction before the item
is changed or reverted back to its
last value.
 If transaction T1 fails for some
reason then A will revert back to its
previous value. But transaction T2
has already read the incorrect value
of A.
 T2 reads the update value of X made by T1, but T1 fails and
rolls back.
 So, T2 reads an incorrect value of X.
 Incorrect Summary Problem

 Consider a situation, where one transaction is applying the

aggregate function on some records while another transaction is
updating these records.
 The aggregate function may calculate some values before the
values have been updated and others after they are updated.
 Transaction T2 is calculating the sum of some records while
transaction T1 is updating them.
 Therefore the aggregate function may calculate some values
before they have been updated and others after they have been
updated.
Incorrect Summary Problem

A= 1000,B=1000,C=1000
Transaction 1 Transaction 2
Lost Update Problem
 Lost Update Problem
 In the lost update problem, an update done to a data item by a
transaction is lost as it is overwritten by the update done by
another transaction.
 A lost update problem occurs due to the update of the same record
by two different transactions at the same time. In simple words,
when two transactions are updating the same record at the same
time in a DBMS then a lost update problem occurs.
 Two transactions T1 and T2 read, modify, write to the same data
item in an interleaved fashion for which an incorrect value is
stored in X . T2 reads the value of X before T1 changes it hence the
updated value resulting from T1 is lost.
 Unrepeatable Read Problem

 This problem occurs when a transaction gets to read unrepeated

i.e. different values of the same variable in its different read
operations even when it has not updated its value.
Unrepeatable Read Problem

 T1 reads the value of X (= 10 say).

 T2 reads the value of X (= 10).
 T1 updates the value of X (from 10 to 15 say) in the buffer.
 T2 again reads the value of X (but = 15).

T2 gets to read a different value of X in its second reading.

T2 wonders how the value of X got changed because according
to it, it is running in isolation.
 Phantom Read Problem

 The phantom read problem occurs

when a transaction reads a variable
once but when it tries to read that
same variable again, an error occurs
saying that the variable does not exist.
 Once transaction T2 reads the variable
X, transaction T1 deletes the variable
X without transaction T2’s knowledge.
Thus, when transaction T2 tries to
read X, it is not able to do it.