Transactions

Sequence of separate requests to a server

to be atomic in the sense that
 They are free from Interference by
operations of other clients
 All-or-Nothing Property

1
 Example

Transaction T:

a.Withdraw(100)
b.deposit(100)
c.withdraw(200)
b.deposit(200)

2
Transaction in Distributed System

A transaction is an execution of a
sequence of client requests transforming
the server data from one consistent state
to another.

3
 Transaction Properties
ACID
Atomicity
Consistency
Isolation
Durability

4
 The Transaction Model (1)
Updating a master tape is fault tolerant.

5
 The Transaction Model (2)
Examples of primitives for transactions.

Primitive Description

BEGIN_TRANSACTION Make the start of a transaction

END_TRANSACTION Terminate the transaction and try to commit

ABORT_TRANSACTION Kill the transaction and restore the old values

READ Read data from a file, a table, or otherwise

WRITE Write data to a file, a table, or otherwise

6
 The Transaction Model (3)
BEGIN_TRANSACTION BEGIN_TRANSACTION
reserve Lhr -> Kar; reserve Lhr -> Kar;
reserve Kar -> Isb; reserve Kar -> Isb;
reserve Isb -> Muree; reserve Isb -> Muree full =>
END_TRANSACTION ABORT_TRANSACTION
(a) (b)

a) Transaction to reserve three flights commits

b) Transaction aborts when third flight is unavailable

7
 Types of Transactions
Flat Transaction
 Type of simple transaction that satisfy ACID
properties.
Nested Transaction
 Transaction constructed from number of sub-
transactions operates on multiple data on multiple
machines.
Distributed Transaction
 Number of flat sub-transactions that operates on
data that are distributed across multiple machines
8
Distributed Transactions
a) A nested transaction
b) A distributed transaction

9
 Implementation
Private Workspace

Each process have its own workspace

containing all the files to which it has access
until it commit or abort.
The index of the blocks is provided to the
processes
if it Aborts Private workspace is simply deleted
If it Commits Private indices are moved to the
parent’s workspace.

10
 Private Workspace

a) The file index and disk blocks for a three-block file

b) The situation after a transaction has modified block 0 and appended block 3
c) After committing

11
 Writeahead Log

 Files are actually modified in place, but before

a block is changed a record is written to a log
telling
Transaction making the change
Old value
New value

12
 Writeahead Log
x = 0; Log Log Log
y = 0;
BEGIN_TRANSACTION;
x = x + 1; [x = 0 / 1] [x = 0 / 1] [x = 0 / 1]
y=y+2 [y = 0/2] [y = 0/2]
x = y * y; [x = 1/4]
END_TRANSACTION;
(a) (b) (c) (d)

a) A transaction
b) – d) The log before each statement is executed

13
 Writeahead Log
if transaction Commits a commit record is
written to the log.

If Transaction aborts, the log is used to

back up the original value starting from the
end and going backward called Rollback.

14
 Concurrency Control (1)

General organization of managers for handling

transactions.

15
Concurrency Control (2)
General organization
of managers for
handling distributed
transactions.

16
 Problems with Concurrency Control
Lost update Problem
 A=100
 B=200
 C=300
Begin Transaction T
Bal=b.getbalance(); $200 Begin Transaction U
b.Setbalance(bal*1.1) $220 bal=b.getbalance(); $200
a.withdrawl(bal/10); $80 b.setbalance(bal*1.1); $220
c.withdraw(bal/10); $280
17
Inconsistent retrieval problem

Transaction V Transaction W
a.withdraw(100) $100
total=a.getbalance(); $100
total=total+b.getbalance(); $300
total=total+c.getbalance();
b.deposit(100) $300

18
 Serializability
Transaction T Transaction U

Bal=b.getbalance(); $200
b.Setbalance(bal*1.1); $220
bal=b.getbalance(); $220
b.setbalance(bal*1.1); $242
a,.withdraw(bal/10); $80
c.withdraw(bal/10); $(278)

19
 Serializability
BEGIN_TRANSACTION BEGIN_TRANSACTION BEGIN_TRANSACTION
x = 0; x = 0; x = 0;
x = x + 1; x = x + 2; x = x + 3;
END_TRANSACTION END_TRANSACTION END_TRANSACTION

(a) (b) (c)

Schedule 1 x = 0; x = x + 1; x = 0; x = x + 2; x = 0; x = x + 3 Legal
Schedule 2 x = 0; x = 0; x = x + 1; x = x + 2; x = 0; x = x + 3; Legal
Schedule 3 x = 0; x = 0; x = x + 1; x = 0; x = x + 2; x = x + 3; Illegal

(d)

a) – c) Three transactions T1, T2, and T3

d) Possible schedules
20
 Recoverability form Aborts

Dirty Reads
Recoverability of Transactions
Cascading Aborts
Premature Writes

21
 Solutions

Locking

Pessimistic Timestamp Ordering

Optimistic Time Stamp Ordering

22
 Two-Phase Locking (1)
Two-phase locking.

23
Strict-Two-Phase Locking (2)
Strict two-phase locking.

24
 Pessimistic Timestamp
Ordering
Concurrency control using timestamps.

25
 Operation Conflicts for Time Stamp
Ordering
Rule Tc Ti
1. Write Read Tc must not write an object that has been read by
any Ti where Ti<Tc. It requires Tc>= max read
timestamp of the object.

2. Write Write Tc must not write an object that has been written by
any Ti where Ti > Tc. It requires Tc > write stamp of
the committed object

3. Read Write Tc must not read an object that has been written by
any Ti where Ti> Tc. It requires Tc > write
timestamp of committed object.

26
Rule: How to decide Write Operation

If (Tc >= max read time on D && Tc >write

timestamp on committed version of D with
write timestamp Tc
Write with timestamp Tc
Else
Abort Transaction

27
 Rule: How to decide Read operation
If (Tc > write timestamp on committed version of D) {
let D be the version with maximum
timestamp <= Tc
If (D is committed )
Read
Else
Wait until that D version commits or
abort then apply read rule again. }
Else
Abort Transaction
28
 Time Stamps in Transactions T and U
Pessimistic time stamp ordering

Tc Ti A B C
RTS WTS RTS WTS RTS WTS
Open Transaction {} S {} S {} S
Bal=b.getbalance() {T}
open Transaction
b.setbalance(bal*1.1) ST
Bal=b.getbalance()
wait for T

a.withdraw(bal/10) ST
Commit T T
Bal=b.getbalance() {U}
b.setbalance(bal*1.1) TU
c.withdraw(bal/10) SU
commit U U

29
Optimistic Timestamp Ordering

Just go ahead and let all the

transactions execute

If there is a problem

Worry about it later

30
 Work Flow
Keeps track of which data items have
been read and written
At the point of committing it checks all
other transactions to see if any of its items
have been changed since it has started
If so Abort
If not Committed

31
 Advantages
Deadlock free
Allow maximum parallelism

Disadvantages
If it fails the transaction has to run again
Failures can occur under heavy load
conditions

32