Distributed Transactions

1
Distributed Transactions

• The Problems and Purposes of Concurrency Control
• Two Phase Locking Principles
• Concurrency Control for Distributed Transactions
• Distributed Deadlock Avoidance and Detection
• Edge Chasing and Variants

2
Purposes of Concurrency Control

• Data synchronization
• Different executing transactions may access to
  the same data objects at the same time, i.e.,
  before a transaction has completed, another
  transaction wants to access to some of its
  accessed data objects
• Data Consistency
• Uncontrolled interleaving of transaction
  execution may result in inconsistent data values
• Maximize system performance
• How to ensure that all executions will result in
  correct data values?
• Prevention method Vs. avoidance method
• I.e., When one process invokes a method
  (operation) to access to a data object, the data
  object is locked (mutual exclusion)
• Blocking Vs. restart
• Minimize the blocking delay and the restart cost
• Maximize the system throughput and minimize the
  response time

3
The lost update problem
Time
Initial account value A100 B200 C300
A schedule shows the execution order of the
operations of two concurrently executing
transactions
4
The inconsistent retrievals problem
Transaction
V


Transaction
W

a.withdraw(100)
aBranch.branchTotal()
b.deposit(100)
a.withdraw(100)
100
total a.getBalance()
100
total totalb.getBalance()
300
total totalc.getBalance()
b.deposit(100)
300
Initial account value A200 B200
5
A serially equivalent interleaving of T and U
A serially equivalent schedule means that the
results from the schedule is equivalent to a
serial schedule, i.e., execute one after one
6
A serially equivalent interleaving of V and W
In a serial schedule, the transactions are
execution one after one
7
Correct Execution of Transactions

• How to make a decision on the correctness of
  execution of a set of concurrent transactions?
• In previous example, we look at the results and
  compared that with the expected one. What will be
  the problem if we do not know the expected
  results?
• Determine the correctness based on the execution
  schedule. In particular the execution of
  conflicting operations
• Conflicting operations two operations A and B
  are in conflict if operation B accesses to a data
  object which has been accessed by operation A
  from another transactions before the completion
  (commit/abort) of the transaction
• Serially equivalent schedule (serializable
  schedule) all pairs of conflicting operations
  from the transactions in the schedule are
  executed in the same order

8
Concurrency Control using Locking

• Methods have to be designed to work with locking
• i.e., Two phase locking
• Mutual exclusion Locking a data object before
  accessing (read/write) it (growing phase)
• Once a transaction releases a lock, it cannot
  submit any lock request (shrinking phase)
• I.e., following the strict requirement, locks are
  released just before the commit of a transaction
• A transaction needs to access to multiple data
  objects
• No sharing of uncommitted data objects in
  conflicting modes among concurrently executing
  transactions

9
Transactions T U with Exclusive Locks
Transaction
T


Transaction
U


balance b.getBalance()
balance b.getBalance()
b.setBalance(bal1.1)
b.setBalance(bal1.1)
a.withdraw(bal/10)
c.withdraw(bal/10)
Operations
Locks
Operations
Locks
openTransaction
bal b.getBalance()
lock
B
openTransaction
b.setBalance(bal1.1)
bal b.getBalance()
waits for
T
s
A
a.withdraw(bal/10)
lock
lock on
B
closeTransaction
unlock
A
,
B


lock
B


b.setBalance(bal1.1)


C
c.withdraw(bal/10)
lock
closeTransaction
unlock
B
,
C
10
Lock Compatibility
For one object
Lock requested


read
write
Lock already set
none
OK
OK
read
OK
wait
write
wait
wait
11
Use of locks in Strict Two-phase Locking
1. When an operation accesses an object within a
transaction (a) If the object is not already
locked, it is locked and the operation
proceeds (b) If the object has a conflicting lock
set by another transaction, the transaction must
wait until it is unlocked (c) If the object has a
non-conflicting lock set by another transaction,
the lock is shared and the operation
proceeds (d) If the object has already been
locked in the same transaction, the lock will be
promoted if necessary and the operation proceeds
(Where promotion is prevented by a conflicting
lock, rule (b) is used) 2. When a transaction is
committed or aborted, the server unlocks all
objects it locked for the transaction
12
Lock class
public class Lock private Object object //
the object being protected by the lock private
Vector holders // the TIDs of current
holders private LockType lockType // the
current type public synchronized void
acquire(TransID trans, LockType aLockType
) while(/another transaction holds the lock
in conflicing mode/) try
wait() catch ( InterruptedException
e)/.../ if(holders.isEmpty()) //
no TIDs hold lock holders.addElement(trans)
lockType aLockType else if(/another
transaction holds the lock, share it/ ) )
if(/ this transaction not a holder/)

holders.addElement(trans) else if (/ this
transaction is a holder but needs a more
exclusive lock/) lockType.promote()
13
continued
public synchronized void release(TransID trans
) holders.removeElement(trans) // remove
this holder // set locktype to
none notifyAll()
14
LockManager class
public class LockManager private Hashtable
theLocks public void setLock(Object
object, TransID trans, LockType lockType)
Lock foundLock synchronized(this) //
find the lock associated with object //
if there isnt one, create it and add to the
hashtable
foundLock.acquire(trans, lockType) //
synchronize this one because we want to remove
all entries public synchronized void
unLock(TransID trans) Enumeration e
theLocks.elements() while(e.hasMoreElements()
) Lock aLock (Lock)(e.nextElement()
) if(/ trans is a holder of this
lock/ ) aLock.release(trans)
15
Concurrency Control using Locking

• Strict execution delay the reading and updating
  of a data object until the previous transaction
  that has updated the same data object has
  committed/aborted
• An execution is recoverable if all the effects
  of an aborted transaction can be removed
  (all-or-none property)
• To ensure recoverability
• If a transaction has read an uncommitted data,
  not allow it to commit before the transaction
  writing the data has committed

16
Recoverability Example
An unrecoverable schedule due to dirty read
Transaction T BankDeposit ( A, 3)
Transaction U BankDeposit ( A, 5)
balance A.Read () 100 A.Write (balance
3) 103
balance A.Read () 103 A.Write (balance
5) 108
Commit transaction
Abort transaction
Dirty read reading uncommitted data objects
17
Locking Rules for Nested Transactions

• Two rules
• Each set of nested transactions is a single
  entity that must be prevented from observing the
  partial effects of any other set of nested
  transactions
• Each transaction within a set of nested
  transactions must be prevented from observing the
  partial effects of the other transactions in the
  set
• Every lock that is acquired by a successful
  sub-transaction is inherited by its parent when
  it completes to prevent other transaction to
  access to the lock until its completion
• Parent transactions are not allowed to run
  concurrently with their child transactions
• Sub-transactions at the same level are allowed to
  run concurrently. When they access the same
  objects, locks serialize their accesses
• For a sub-transaction to acquire a read/write
  lock, no other transaction can have a write lock
  on it except the parent transaction
• When a sub-transaction commits, its locks are
  inherited by its parent
• When a sub-transaction aborts, its locks are
  discarded

18
Nested Transactions Example
commit
Suppose T1, T2 and T11 all access to a common
object Suppose that T1 accesses the object first
and successfully acquire a lock, which it passes
on to T11 for the duration of its execution,
getting it back when T11 completes. When T1
completes, T inherits the lock and passes it to T2
19
Concurrency Control for Distributed Transactions

• Distributed Locking Vs centralized Locking
• Centralized locking
• A central server maintains a lock table
• The central server is responsible for the locking
  of all the data objects in the system
• All data access requests will be forwarded to the
  central server for locking first
• Distributed locking
• Each server maintains a lock table for the
  locking of the data objects managed by it
• A data access request will be forward to the
  server responsible for locking that data object
• Both distributed and centralized locking may
  result in deadlock

20
Deadlock with write locks
Transaction
U
Transaction
T

Operations
Locks
Operations
Locks

a.deposit(100)
write lock
A
b.deposit(200)
write lock
B
b.withdraw(100)
waits for
U
s
a.withdraw(200)
waits for
T
s
lock on
B
lock on
A
21
Management of Blocking Lock Requests

• A lock table to show the locking of each data
  object
• Maintain a block queue to show the waiting order
  of the requests from different transactions for
  the same data object
• When a lock release request is completed, the
  lock table is updated and the block queue will be
  searched
• If multiple requests are waiting for the lock,
  which one should be selected for granting the
  lock
• The wait-for-graph is built from the block queues
• Wait-for-graph shows the wait-for relationships
  of the blocked and holder transactions
• T1 -gt T2 T1 is requesting a lock which is
  currently holding by T2

22
The wait-for graph
23
A cycle in a wait-for graph
24
Another wait-for graph
25
Distributed Deadlocks

• Deadlock involving processes located at more than
  one server is called distributed deadlock
• Deadlock avoidance Vs deadlock detection
• Deadlock avoidance
• To prevent the formation of deadlock cycle
• I.e. add rules in serving lock requests such that
  deadlock cycle is impossible to form (i.e., a
  change in locking procedure)
• Deadlock detection
• Following the original rules for granting a lock
• Periodic (conditionally) search the wait-for
  graph for deadlock cycle
• In a distributed deadlock, the (global) WFG is
  partitioned at multiple servers
• How to search the global WFG without incurring
  heavy workload (network servers)?

26
Deadlock Avoidance using TS

• Deadlock avoidance prevent potential deadlock to
  become deadlock
• What is a potential deadlock? T1-gtT2
• Each transaction is assigned a unique time-stamp,
  e.g., its creation time (distributed dbs
  creation time site ID)
• Wait-die Rule (non-preemptive)
• If Ti requests a lock that is already locked by
  Tj, Ti is permitted to wait if and only if Ti is
  older than Tj (Tis time-stamp is smaller than
  that of Tj)
• If Ti is younger than Tj, Ti is restarted with
  the same time-stamp
• When Ti requests access to the same lock in the
  second time, Tj may already have finished its
  execution
• Wound-Wait Rule (preemptive)
• If Ti requests a lock that is already locked by
  Tj, Ti is permitted to wait if and only if Ti is
  younger than Tj
• Otherwise, Tj is restarted (with the same
  time-stamp) and the lock is granted to Ti

27
Deadlock Avoidance using TS

• If TS(Ti) lt TS(Tj), Ti waits else Ti dies
  (Wait-die)
• If TS(Ti) lt TS(Tj), Tj wounds else Ti waits
  (Wound-wait)
• Note a smaller TS means the transaction is older
• Note both methods restart the younger transaction
• Both methods prevent cyclic wait
• Consider this deadlock cycle T1-gtT2-gtT3-gt-gtTn-gtT
  1
• It is impossible since if T1 -gtTn, then Tn is
  not allowed to wait for T1
• Wait-die Older transaction is allowed to wait
• Wound-wait Older transaction is allowed to get
  the lock

28
Deadlock Example
Transaction U TS of U lt TS of T
Transaction T
Read (A) Write (B)
Read (C) Write (A) (blocked)
Write (C) (blocked) deadlock formed

29
Deadlock Example (wait-die)
Transaction U TS of U lt TS of T
Transaction T
Read (A) Write (B)
Read (C) Write (A) (restarts) T is
restarted since it is younger than U T
releases its read lock on C before restart
Write (C)

30
Deadlock Example (wound-wait)
Transaction U TS of U lt TS of T
Transaction T
Read (A) Write (B)
Read (C) Write (A) (blocked) since T is
younger than U
Write (C) T is restarted by U since T is
younger than U The write lock on C is granted
to U after T has released its read lock on C

31
Deadlock Resolution by time-out

• Deadlock detection allow deadlock to form but
  periodically check for deadlock. Once a deadlock
  is detected, it will be resolved by restating one
  of the deadlocked transactions
• A simple method to break a deadlock cycle is the
  time-out method
• Once a deadlock is formed, it will exist forever
  until it is resolved
• In the time-out method, two parameters are
  defined a time-out period (TP) and a time-out
  checking period (TCP). Normally, TPgtgtTCP
• The time-out checking period defines the period
  for checking the blocked transactions (at the
  lock table) for deadlock
• If a transaction has been blocked for a period of
  time greater than the time-out period, it will be
  restarted as it is assumed to be involved in a
  deadlock
• So, no deadlock cycle exists in the system longer
  than TP TPC

32
Resolution of the deadlock
Transaction T
Transaction U


Operations
Locks
Operations
Locks


write lock
A
a.deposit(100)
write lock
B
b.deposit(200)
b.withdraw(100)
a.withdraw(200)
waits for
waits for Ts
s
U
lock on
B
lock on
A
(timeout
elapses)

Ts lock on
A
becomes vulnerable,
unlock
A
, abort T
a.withdraw(200)
A
write locks
unlock
A
,
B
A transaction is aborted if its waiting time for
a lock is longer than a pre-defined threshold
33
Deadlock Resolution by time-out

• The problems in using the time-out method
• How to define the time-out period (and TCP)
• If it is large, a deadlock cycle will exist in
  the system for a long period of time
• If it is small, many transactions will be
  restarted even though they are not involved in
  any deadlocks (false deadlock)
• The advantages
• Simple in implementation and the overhead of
  using the time-out method is low and depends on
  the values of TCP and TP
• No undetected deadlock (can resolve all
  deadlocks)

34
Distributed Deadlock Resolution

• Each scheduler maintains a lock table
• Lock table holder ID, requester ID, block time
• Local wait-for graph S1 T1 -gt T2 -gt T3
• At site 1, T1s lock request is blocked. T1 is
  requesting a lock which is currently holding by
  T2. T2 is requesting a lock being held by T3
• Local deadlock can be detected by local wait-for
  graph
• Local wait-for graph S1 T1 -gt T2 -gt T3-gtT1
• Periodically search the local wait-for graph for
  deadlock
• Once a deadlock is found, one of the three
  transactions needs to be restarted, release all
  its locks and abort/restart from its first
  operations
• I.e., T2 is restarted. Then, T1 can get its
  requesting lock. When T1 is finished, T3 can get
  its requesting locks to finish. T2 can get its
  requesting lock at the restart time
• Distributed deadlock
• No local deadlocks but globally, there may be a
  deadlock
• Need the merge of local wait-for graph for
  distributed deadlock detection

35
Interleaving of Transactions U, V and W
U
V
W
lock
D
d.deposit(10)
lock
B
b.deposit(10)
at
Y
lock
A
a.deposit(20)
at
X
lock
C
c.deposit(30)
at
Z
wait at
Y
b.withdraw(30)
wait at
Z
c.withdraw(20)
wait at
X
a.withdraw(20)
36
Distributed Deadlock
(a)
(b)
37
Local and Global wait-for Graphs
38
Distributed Deadlock Detection

• Merging the local WFGs at different servers to
  build a global wait-for graph
• How and when to submit the local WFG at a server
  to other servers?
• Too frequent heavy overhead
• Too infrequent
• phantom deadlock (a deadlock is detected but it
  is not a real one)
• Blocking time is long
• Edge chasing
• To reduce the detection overhead,
• Send the blocking relationship when a transaction
  is blocked
• Not to send the local WFG to all servers. Only to
  those there is a potential deadlock
• Not to send the whole WFG. Only sending the nodes
  that are sufficient for deadlock detection

39
Edge Chasing

• The servers attempt to find deadlock cycles by
  forwarding probes, which follow the edges of the
  graph throughout the distributed system
• A probe consists of transaction wait-for
  relationships representing a path in the global
  wait-for graph (ltT-gtUgt indicating T is blocked by
  U)
• When a probe returns to the server that generates
  it, a distributed deadlock is detected
• Initiation step
• When a server notes that a transaction T starts
  waiting for another blocked transaction U (lock
  reject), it initiates a detection by sending a
  probe containing the edge ltT-gtUgt to the server
  that of the object at which U is blocked. If U is
  sharing a lock, probes are sent to all the
  holders of the lock

40
Edge Chasing

• Detection step
• When a server receives a probe ltT-gtUgt, it checks
  whether U is still waiting. If yes (i.e., waiting
  for V), it adds the edge to the probe ltT-gtU-gtVgt.
  If V is blocked, forward the update probe to the
  server that V is waiting
• Resolution when a deadlock cycle is formed, a
  transaction in the cycle is selected to rollback
  (release all its locks)

41
Probes transmitted to detect deadlock
42
Edge Chasing with Priorities

• U-gtW V-gtT at about the same time, T requests an
  object locked by U and W is blocked by V
• Two probes are triggered and the deadlock cycle
  is detected twice
• Transactions are prioritized to reduce the number
  of probes (from higher priority to lower
  priority, TgtUgtVgtW)
• Aborting the lowest priority transaction in the
  deadlock cycle
• Reducing the number of probes
• T-gtU initiates a probe
• W-gtV, W-gtV, the probe will not be sent
• How about if W is blocked by V is the last formed
  edge in the cycle?

43
Two probes Initiated
(c) detection initiated at object requested by W
(a) initial situation
(b) detection initiated at object requested by T
44
Probe Travel Downhill

• When a transaction starts waiting for an object,
  it forwards the probes in its queue to the server
  of the object, which propagates the probes on
  downhill routes
• When U starts waiting for V, the coordinator of V
  will save the probe ltU-gtVgt
• When V starts waiting for W, the coordinator of W
  will store ltV-gtWgt and V will forward its probe
  queue ltV-gtWgt to W
• When W starts waiting for A, it will forward its
  probe queue ltU-gtV-gtWgt to the server of A, which
  also notes the dependency W-gtU and combines the
  information in the received probe U-gtV-gtW-gtU

45
Probes Travel Downhill
.
.
(b) Probe is forwarded when V starts waiting
(a) V stores probe when U starts waiting
46
References

• 13.1 to 13.41, 14.41, 14.5 (Dollimore)