1/5/2016

Objectives
2

To understand leader election algorithms

Transactions
Concurrency Control
Recoverability
Distributed Transactions
Atomic commit protocols

DISTRIBUTED SYSTEMS
Distributed Transactions

What are Transactions?

3

What are Transactions?

4

Suppose that you are booking a flight from Mombasa to

Florida.
You go to the travel agents they tell you that you must:

Fly Mombasa to Dubai

Dubai to Chicago

Chicago to Florida.

You say OK, book the flights they start to book the flights one
by one and discover on the last flight that it is full.
The next free flight from Chicago to Florida is the next day.
So you have to wait all a whole day in Chicago.

Not an optimal situation.

You want to either book all the flights or book none of them.
You dont want a half completed booking.

The problems is that other people might be booking flights at the same
time and hence some flights might get full while you think they are
empty.

Especially if the half completed booking commits you to do something

that you dont want too(spending a night at Chicago).

A transaction is a sequence of operations with an all or

nothing behavior.

1/5/2016

What are Transactions?

5

ACID Properties of a Transaction

6

1.

2.

Transactions are atomic as:

they are free from interference by operations being
performed on behalf of other concurrent clients;
either all of the operations must be completed
successfully or they must have no effect at all (even
in the presence of server crashes)

Atomicity: a transaction must be all or nothing;

Consistency: a transaction takes the same from one
consistent state to another consistent state;
Isolation; transactions should be run as if they are
they only transaction running (they should not be
interfered with by another transaction);
Durability: when the transaction commits it should be
recoverable in case of server failure

Problems with Transactions

Concurrency Control

The problem with transaction is that we want to do

them efficiently.

An inefficient way of doing things: To stop access to the

server by anybody else while a transaction has started
and only grant access when this person has finished.

We should allow many transactions to go on at the

same time and try to stop bad things happening
when we do things at the same time.

(if the server crashes after I have booked my flight, the

flight is still booked).

Problems with Transactions

Concurrency Control

Several things can go wrong when we

merge transactions e.g.:
The

Lost Update Problem

Uncommitted data dependency
Inconsistent retrievals

1/5/2016

Normal Execution of Two

Transactions

Lost Updates
An appropriate successfully completed update operation
by one user can be overridden by another user.

If these transactions were executed serially one after the other

with no interleaving of operations, the final stored value would
be 105 no matter which transaction is performed first

Correct Execution of Two

Transactions

An Uncommitted Data
Dependency Problem
Occurs when one transaction is allowed to see the intermediate
results of another transaction before it has committed

T1 has been cancelled. Thats ok.

1/5/2016

Retrieval During Update

Transaction Results:
Data Entry Correction

Database Systems Notes - Tx

Inconsistent Retrievals

Database Systems Notes - Tx

Inconsistent Retrievals

Transactions that only read the database can obtain

inaccurate results if they are allowed to read partial results
of incomplete transactions, which are simultaneously
updating the database.
Occurs when a transaction reads several values from the
database but a second transaction updates some of
them during the execution of the first
e.g.

the transaction that is summing data in the database

(totaling productQOH) will obtain inaccurate results if, while
it is executing, other transactions are updating the
database.

Database Systems Notes - Tx

Database Systems Notes - Tx

1/5/2016

Distributed Transactions
18

Distributed Transactions

17

One Phase commit

19

A distributed transaction is a single transaction on

multiple servers.
A transaction has a number of participants.
Because transactions need to be atomic we want to
have some mechanism so that all the participants do
the transaction or none of them.

One Phase commit problem

20

A transaction should be atomic

when a distributed transaction comes to an end, either all
of its operations are carried out or none of them.
A transaction comes to an end when the client requests
that a transaction be committed or aborted.

A simple way to complete the transaction in an atomic

manner is for the coordinator to communicate the
commit or abort request to all of the participants in
the transaction.
The coordinator repeats the request until all
participants acknowledge they have carried it out.

The one phase commit is fine as long as

every body wants to commit.
The coordinator might need to abort the
transaction because of concurrency
control issues or deadlocks.
The 1PC does not allow either the
coordinator or participants to abort
transactions.

1/5/2016

Two Phase Commit

21

Two Phase Commit

22

2PC has two phases;

a voting phase where all the participants vote
a second phase where they agree on an abort or
commit action.

1.

2.

Phase 1 (voting phase)

The coordinator sends a canCommit? request
to each of the participants in the transaction.
When a participant receives a canCommit?
request it replies with its vote (yes or no) to
the coordinator.

Before voting Yes it prepares to commit by saving

objects in permanent storage otherwise it aborts.

Two Phase Commit

23

1.

Phase 2
The coordinator collects the votes (including its own).

2.

If there are no failures and all the votes are Yes the
coordinator sends a doCommit request to each of the
participants.
Otherwise the coordinator sends a doAbort request to all
participants that voted Yes.

Participants that voted Yes are waiting for a

doCommit or doAbort request from the coordinator.

When a participant receives a message it acts

accordingly.