You are on page 1of 11

UVA

DEPARTMENT OF COMPUTER SCIENCE

Distributed Database Systems

Advantages
- autonomy
- resource sharing
- high performance
- high reliability
- flexibility

Disadvantages
increased complexity in
- atomic commitment
- concurrency control
- recovery management

2PC-1

UVA

DEPARTMENT OF COMPUTER SCIENCE

Distributed Recovery

Reliability issues in distributed environments


- major difference from single-node database:
commit/abort of transactions
- processing of logically single operation must
take place in multiple places in distributed DBS

Nature of failure
- all or nothing in a centralized system
- partial operability in distributed systems:
partial failure vs total failure
- partial failures are tricky to deal with since
operational sites are uncertain about the state of
sites either failed or it cannot communicate with
- operational sites may need to be blocked

2PC-2

UVA

DEPARTMENT OF COMPUTER SCIENCE

Atomic Commitment

Transaction commit
- consistent termination of transaction is an issue:
atomic commitment protocols (ACP)
- an important goal of ACP is to minimize the effect
of failures on operational sites ability to continue

Atomic commitment protocol


- all the participating sites must agree: commit/abort
- each casts one of the two votes (yes/no)
and reaches exactly one of the two: commit/abort

2PC-3

UVA

DEPARTMENT OF COMPUTER SCIENCE

Properties of ACP

AC1: consistent termination


- all sites that reach a decision reach the same one

AC2: irrevocable decision


- a site cannot reverse its decision after it is made

AC3: unanimous consent


- everyone must agree before anyone can commit

AC4: exclusion of trivial protocols


- if no failure and all sites vote yes,
decision must be commit
- avoids useless protocol where everyone always
decides to abort

AC5: finite time in decision making


- if failures can be tolerated by ACP, all sites
eventually reach a decision in a finite time

2PC-4

UVA

DEPARTMENT OF COMPUTER SCIENCE

Formal Model of Atomic Commit Protocols

Commit point
- a point reached during the execution of a transaction
at which its fate is determined
"From a certain point onward, there is no longer any
turning back. That is the point that must be reached."
- Kafka

Commit
- unconditional guarantee to execute the transaction
to completion, even in the events of failures

Abort
- unconditional guarantee to back out the transaction
so that none of its effect persist in the database

2PC-5

UVA

DEPARTMENT OF COMPUTER SCIENCE

Atomic Commit Protocols

Irreversible decision
- both commit and abort are irreversible
- if failure occurs before the commit point, then
upon recovery, it must be aborted
- in distributed databases, the task of ACP is
to enforce global atomicity --- unanimity

Why difficult?
- in the absence of failures, unanimous consensus
protocol is rather easy to achieve
- challenge is to find protocols ensuring atomicity
in various types of failure situations

Types of failures
- site (node) failures
- communication link failures

2PC-6

UVA

DEPARTMENT OF COMPUTER SCIENCE

Two-Phase Commit Protocol

Two-phase commit (2PC) protocol


- coordinator and participants
- during the first phase, any participating site
can unilaterally abort the transaction
- by the end of the first phase, all sites has given
up the right to abort the transaction unilaterally
- fundamental weakness: vulnerability to site failures
especially to the failure of the coordinator
- it could result in blocking situations

Blocking
- although it preserves consistency, it is undesirable
- locks cannot be released, making data inaccessible

Window of uncertainty
- period of time during which participants cannot
make unilateral decision

2PC-7

UVA

DEPARTMENT OF COMPUTER SCIENCE

Two-Phase Commit Protocol

Protocol for the coordinator:


Phase 1: send "start transaction" message to all participants
wait for votes from each participant
Phase 2: if all the votes are YES, then send COMMIT to all
participants and commit the transaction
else send ABORT and abort the transaction
Protocol for the participants:
Phase 1: receive "start T" from the coordinator
execute subtransaction and send vote to coordinator
YES to commit
NO to abort
wait for the final decision from coordinator
Phase 2: receive either COMMIT or ABORT and process it

2PC-8

UVA

DEPARTMENT OF COMPUTER SCIENCE

Timeout Actions in 2PC Protocol

In 2PC, a process waits for a message as follows:


1. Coordinator waits for votes from participants
timeout action: abort and send ABORT to participants
2. Participant is waiting for the final decision
timeout action: termination protocol
g

Termination protocol in 2PC


- simple protocol: participant is remained blocked
until it can establish communication with coordinator
- cooperative: participant sends a decision-request
message to other participants
- cooperative protocol could reduce probability of blocking
but cannot eliminate it, and with additional overhead

2PC-8

UVA

DEPARTMENT OF COMPUTER SCIENCE

Independent Recovery in Distributed Databases

Independent recovery
- ability of a recovering process to reach a decision
without communicating with other processes
- very attractive, but not quite feasible
- possible to design an ACP without uncertainty period?
it requires that a process casts its vote and learns
the votes of all others all at once; not possible

Theorem 1:
If communication failures or total failures are
possible, every ACP may cause blocking processes
Theorem 2:
NO ACP can guarantee independent recovery of
failed processes

2PC-10

UVA

DEPARTMENT OF COMPUTER SCIENCE

Evaluation of ACP

Blocking problem of 2PC


A process need to wait for messages before proceeding,
while messages may not arrive due to failures
--- it must take special "time-out" action
- if not in uncertainty period, abort T
- in uncertainty period, it cannot abort unilaterally
--- cooperative termination protocol

Reliability and performance aspects


- resiliency: types of failures it can tolerate
- blocking: can a process blocked?
- time complexity: how long?
- message complexity: how many messages?
- reliability and efficiency are conflicting goals:
each can be achieved at the expense of the other)

2PC-11

You might also like