1. Distributed Transactions
What is a transaction?
(A sequence of server operations that must be carried out atomically)
ACID properties - what are these
(Atomicity, Consistency, Isolation, Durability)
What is a distributed transaction?
-Involves objects managed by multiple servers communicating with one another.

2. Distributed Transactions
What is a transaction?
(A sequence of server operations that must be carried out atomically)
ACID properties - what are these
(Atomicity, Consistency, Isolation, Durability)
What is a distributed transaction?
-Involves objects managed by multiple servers communicating with one another.

3. Distributed Transactions
What is a transaction?
(A sequence of server operations that must be carried out atomically)
ACID properties - what are these
(Atomicity, Consistency, Isolation, Durability)
What is a distributed transaction?
-Involves objects managed by multiple servers communicating with one another.

4. Transactions Permanent Record Commit / Abort Shared variables Server
operation
Server
operation
Server
operation
Server
operation

5. Concurrency control
The goal of concurrency control is to guarantee that when multiple transactions are concurrently executed, the net effect should be equivalent to executing them in some serial order. This is the essence of the serializability property.

6. Example 1 T1 starts (20) W(x:=1) [OK] R(x) [OK] T1 commits
T2 starts(30) W(x:=2) [OK] T2 commits
T3 starts (40) W(x:=3) [OK] R(x) T3 commits
This is serializable. Think of other examples too.

7. Example 2 T1 starts (20) W(x:=1) [OK] R(x) [NO] T1 aborts
T2 starts(30) W(x:=2) [OK] R(x) T2 commits?
T3 starts (40) W(x:=3) [OK] T3 commits
This is not serializable.

8. Pitfalls in concurrency control
Dirty read
Lost update
Premature write

9. Lost update Initially, B= $1000 Amy’s transaction Bob’s transaction
1 Load B into local 4 Load B into local
Add $250 to local Add $250 to local
Store local to B 6 Store local to B
What if the interleaving is ? The final value of B is $1250, although it should have been $1500

10. Dirty read Initially B= $1000 Amy’s transaction Bob’s transaction
1 Load B into local 4 Load B into local
Add $250 to local Add $250 to local
Store local to B 6 Store local to B
ABORT COMMIT
Execute the actions in the sequence If Amy’s transaction aborts after Bob executes step 4, then the final result is still $1500, although it should have been $1250

11. Premature write {Initially B = 0} Amy’s transaction Bob’s transaction
1 B:= $ B := $1000
3 COMMIT
4 ABORT
B changes to 0. This could have been avoided if the
second transaction postponed its commit UNTIL
the first transaction commits or aborts.

12. Locks
Locks are commonly used to implement serrializability of concurrent transactions. Operations on shared objects are in conflict when one of them is a write operation. Each transaction must acquire the corresponding exclusive lock before executing an action.
Locks can be fine grained. Note that there is no conflict between two reads.

13. Serializability
The serialization graph is a directed graph (V, E) where V is the set of transactions, and E is the set of directed edges between transactions - a directed edge from a transaction Tj to a transaction Tk implies that Tk applied a lock only after Tj released the corresponding lock. Tj Tk

14. Serializability theorem
For a set of concurrent transaction, the serializability property holds if and only if the corresponding serialization graph is acyclic
[Proved by Bernstein, Goodman, Hadzilacos in 1987]

15. Two-phase locking (2PL)
Phase 1. Acquire all locks needed to execute the transaction. The locks will be acquired one after another, and this phase is called the growing phase or acquisition phase
Phase 2. Release all locks acquired so far. This is called the shrinking phase or the release phase.

16. Two-phase locking (2PL)
acquire
release
Growing phase
Shrinking phase

17. 2PL Theorem. 2PL guarantees serializability.
Proof. Suppose that the theorem is not correct. Then the serialization graph must contain a cycle …Tj  Tk  … Tm  Tj …This implies that Tj must have released a lock (that was later acquired by Tk) and then acquired a lock (that was released by Tm). However this violates the condition of two-phase locking that rules out any locking once a lock has been released.

18. Atomic Commit Protocols
Network of servers
The initiator of a transaction is called the coordinator,
and the remianing servers are participants S1
Servers may crash S3 S2

19. Requirements of Atomic Commit Protocols
Network of servers
Termination. All non-faulty servers must eventually reach an irrevocable decision.
Agreement. If any server decides to commit, then every server must have voted to commit (i.e. no one voted abort).
Validity. If all servers vote commit and there is no failure, then all servers must commit (as opposed to all deciding to abort)
Irreversibility. Each participant decides at most once (i.e. decision is not reversible)
Servers may crash S3 S2

20. One-phase Commit server participant server server client participant
coordinator
server
participant
If a participant deadlocks or faces a local problem then the
coordinator may never be able to find it. Too simplistic.

21. Two-phase commit (2PC) What if failures occur?
Phase 1: The coordinator sends VOTE to the participants. and receive yes / no from them.
Phase 2:
if ∀server j: vote(j) = yes  multicast COMMIT to all severs
[] ∃ server j : vote (j) = no  multicast ABORT to all servers fi
What if failures occur?

22. Failure scenarios in 2PC
(Phase 1)
Fault: Coordinator did not receive YES / NO: OR
Participant did not receive VOTE:
Solution: Broadcast ABORT;
Abort local transactions

23. Failure scenarios in 2PC
(Phase 2)
(Fault) A participant does not receive a COMMIT or an ABORT message from the coordinator
(it may be the case that the coordinator crashed after sending ABORT or COMIT to a fraction of the servers). The participant remains undecided, until the coordinator is repaired and reinstalled into the system.
This blocking is a known weakness of 2PC.

24. Coping with blocking in 2PC
A non-faulty participant can ask other participants about
what message (COMMIT or ABORT) did they receive
from the coordinator, and take appropriate actions.
But what if no non-faulty participant* received anything?
Who knows if the coordinator committed or aborted the
local transaction before crashing? Continue to wait …
*May be some participant received COMMIT/ABORT, but it crashed.

25. Non-blocking Atomic Commit
A blocking protocol has the potential to prevent non-faulty participants from reaching a final decision.
A solution to the atomic commitment problem is called non-blocking, if in spite of server crashes, every non-faulty participant eventually decides.
One solution is to impose the requirement of uniform agreement

26. Uniform agreement
If any participant (faulty or not) delivers a message m
(commit or abort) then all correct processes eventually
deliver m.
To implement uniform agreement, no server should deliver a COMMIT or ABORT message until it has relayed it to all other servers.
If a process times out in phase 2, then it decides abort.

27. Recovery: Stable storage
Creates the illusion of an incorruptible storage, even if
a writer or a disk crashes at any time. The implementation
Uses at least two independent disks. A0 A1
inspect
update

28. Stable storage A0 update inspect A1 To write, do the following:
1. copy on disk A0;
2. record timestamp T0;
3. compute checksum S0;
4.copy on disk A1;
5. record timestamp T1;
6. compute checksum S1
Readers check four cases:
Both checksums OK and T1>T0 {accept any}
Both checksums OK and T1<T0 {accept A0} {failure between 3 & 4}
Checksum on A1 wrong {accept A0}
Checksum on A0 wrong {accept A0}
(Which copy to accept in each case?) A0
update A1
inspect

29. Checkpointing
Mechanism for (backward) error recovery. Transaction states are periodically stored on stable storages. Following a failure, the transaction rolls back to the nearest checkpoint.
Independent (unsynchronized) or coordinated (synchronized) checkpointing

30. Classification of checkpointing
Coordinated Checkpointing takes a consistent snapshot.
Has some overhead.
Uncoordinated checkpointing apparently has no overhead.
But it may have some efficiency problems.