0% found this document useful (0 votes)
11 views14 pages

Transactions Lecture 2

Informative management system- 2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views14 pages

Transactions Lecture 2

Informative management system- 2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 14

Transactions

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 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
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 :
Before transaction: A=500
B=600 Total=1100
A=500 After Transaction : A=405
A=450 B=695 Total=1100

B=600
B=650

A=450
temp=45
A=405

B=650
B=695
Before transaction: A=500

Schedule 2 B=600 Total=1100

• A serial schedule where T2 is followed by T1


Schedule 3

 Let T1 and T2 be the transactions defined previously. The following schedule is not a
serial schedule, but it is equivalent to Schedule 1.
Before transaction: A=500
B=600 Total=1100
A=500
After Transaction : A=405
A=450 B=695 Total=1100

A=450
Temp=
45
B=600 A=405
B=650

B=650
B=695

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


Before transaction: A=600
B=500 Total=1100 Before transaction:

Schedule 4 After Transaction : A=550


B=560 Total=1110
A=500

*D=Disk *M=Memory B=600 Total=1100


 The following concurrent schedule does not preserve the value of (A + B ).

A(D)=600, B(D)=500 A(D)=600, B(D)=500


A(M)=600
A(M)=550
A(M)=600
temp=60
A(M)=540
A(D)=540
B(M)=500
A(D)=550
B(M)=500
B(M)=550
B(D)=550
B(M)=56
0
B(D)=560
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.

 Thus, there are three types of conflicts: – Read-Write conflicts (RW) – Write-
Read conflicts (WR) – Write-Write conflicts (WW)
Anomalies with Interleaved
Execution
 Temporary Update Problem/ Dirty Read (Write-Read
Conflict)
 Lost Update Problem (Write-Write Conflict)
 Unrepeatable Read Problem (RW Conflicts):
 Phantom Read Problem
 Incorrect Summary Problem
Anomalies with Interleaved
 Execution
Temporary Update Problem (WR Conflicts, “dirty reads”):
 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.

A=10 A=10

A=10
A=10-2=8 A=8
Write=8-8=0

B=15
B=15-2=13
 Unrepeatable Reads (RW Conflicts): The
unrepeatable read problem occurs when two or
more read operations of the same transaction
read different values of the same variable.
 Lost update/ Overwriting Uncommitted Data (WW Conflicts):
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.
Phantom read:

 Phantom read: 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.
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.
Summary

• Lost Update: nullifies the update of the first


transaction violating ACID properties., prevented via setting
isolation level, Optimistic lock, pessimistic lock, Atomic write
operations
• Dirty read : reading uncommitted data
• Unrepeatable read problem : Different value for same data
set variable
• Phantom read : losing the variable or data set on second
operation
• Incorrect summary problem : invalid result on aggregating
data

You might also like