CS 582 / CMPE 481 Distributed Systems

1
CS 582 / CMPE 481Distributed Systems

• Concurrency Control

2
Class Overview

• Transactions
• Why Concurrency Control
• Concurrency Control Protocols
• pessimistic
• optimistic
• time-based
• Deadlocks

3
Transactions

• Definition
• a sequence of one or more operations on one or
  more resources that is
• atomic all or nothing
• consistent takes system from one consistent
  state to another
• isolated intermediate states invisible to others
  (serializable)
• durable once completed (committed), changes are
  permanent
• Primitives
• BeginTransaction
• start transaction and get an ID
• EndTransaction
• commit (make all writes durable) or abort
  (discard all changes made by writes) transaction
• AbortTransaction
• Read, Write, ...

4
Why Concurrency Control?

• Increase efficiency by allowing several
  transactions to execute at the same time
• Concurrent access to a shared resource may cause
  inconsistency of the resource
• inconsistency examples
• lost updates
• two transactions concurrently perform update
  operation
• inconsistent retrievals
• performing retrieval operation before or during
  update operation

5
Concurrency Control

• Basic Principle
• To avoid possible problems due to concurrent
  access, effect of operations of related
  transactions must be as if the transactions were
  executed in some serial order
• serialized (one-at-a-time)

Layered managers
6
Serializability

• Schedule is serial if the steps of each
  transaction occur consecutively.
• Schedule is serializable if its effect is
  equivalent to some serial schedule.

BEGIN_TRANSACTION x 0 x x 1END_TRANSACTION T1 BEGIN_TRANSACTION x 0 x x 2END_TRANSACTION T2 BEGIN_TRANSACTION x 0 x x 3END_TRANSACTION T3
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
7
Serializability (cont)

• transaction can be modeled as a log of read and
  write operations
• were not concerned with the computations of each
  transaction
• Two operations OPER(Tix) and OPER(Tjx) on the
  same data item x, and from a set of logs may
  conflict at a data manager
• read-write conflict (rw)
• One is a read operation while the other is a
  write operation on x
• write-write conflict (ww)
• Both are write operations on x

8
Basic Scheduling Theorem

• Let T T1, , Tn be a set of transactions and
  let E be an execution of these transactions
  modeled by logs L1, , Ln. E is serializable
  if there exists a total ordering of T such that
  for each pair of conflicting operations Oi and Oj
  from distinct transactions Ti and Tj
  (respectively), Oi precedes Oj in any log L1, ,
  Ln if and only if Ti precedes Tj in the total
  ordering.
• For concurrency control, process conflicting
  reads and writes in certain relative orders.
• read-write and write-write conflicts can be
  synchronized independently, as long as we stick
  to a total ordering of transactions that is
  consistent with both types of conflicts.

9
Concurrency Control Protocols

• Two-phase locking Before reading or writing a
  data item, a lock must be obtained. After a lock
  is given up, the transaction is not allowed to
  acquire any more locks.
• Timestamp ordering Operations in a transaction
  are timestamped, and data managers are forced to
  handle operations in timestamp order.
• Optimistic control Dont prevent things from
  going wrong, but correct the situation if
  conflicts actually did happen.
• Basic assumption you can pull it off in most
  cases.

10
Two-Phase locking

• Clients do only READ and WRITE operations within
  transactions
• Locks are granted and released only by scheduler
• read locks vs. write locks
• Locking policy is to avoid conflicts between
  operations
• serializable schedules
• Two-Phase Commit
• modify data items only after lock point
• lock point is when all locks have been acquired

11
Two-Phase locking (cont)

• Rule 1
• When client submits OPER(Ti,x), scheduler tests
  whether it conflicts with an operation OPER(Tj,x)
  from some other client.
• If no conflict then grant LOCK(Ti,x), otherwise
  delay execution of OPER(Ti,x)
• Conflicting operations are executed in the same
  order as that locks are granted
• Rule 2
• If LOCK(Ti,x) has been granted, do not release
  the lock until OPER(Ti,x) has been executed by
  data manager
• Guarantees LOCK ! OPER ! RELEASE order
• Rule 3
• If RELEASE(Ti,x) has taken place, no more locks
  for Ti may be granted
• Combined with rule 1, guarantees that all pairs
  of conflicting operations of two transactions are
  done in the same order

12
Two-Phase locking - Problems

• Problems
• System can come into a deadlock.
• Practical solution put a timeout on locks and
  abort transaction on expiration
• When should the scheduler actually release a lock
• when operation has been executed
• when it knows that no more locks will be
  requested
• No good way of testing unless transaction has
  been committed or aborted.
• Assume the following execution sequence takes
  place
• RELEASE(Ti,x) ! LOCK(Tj,x) ! ABORT(Ti).
• Consequence scheduler will have to abort Tj as
  well
• cascaded aborts
• Solution Release all locks only at commit/abort
  time
• strict two-phase locking

13
Time stamp ordering

• Transaction manager assigns a unique timestamp
  TS(Ti) to each transaction Ti.
• Each operation OPER(Ti,x) submitted by the
  transaction manager to the scheduler is
  timestamped
• TS(OPER(Ti,x)) ? TS(Ti).
• Scheduler adheres to following rule
• If OPER(Ti,x) and OPER(Tj,x) conflict
• then data manager processesOPER(Ti,x) before
  OPER(Tj,x)
• iff TS(OPER(Ti,x)) lt TS(OPER(Tj,x))
• aggressive
• if a single OPER(Ti,x) is rejected, Ti will have
  to be aborted.
• if TS(OPER(Ti,x)) lt TS(OPER(Tj,x))
• but OPER(Tj,x) has already been processed by the
  data manager.
• Then scheduler rejects OPER(Ti,x)
• it came in too late.
• if TS(OPER(Ti,x)) lt TS(OPER(Tj,x))
• OPER(Ti,x) has already been processed by the data
  manager
• Then scheduler would submit OPER(Tj,x) to data
  manager.
• Refinement hold back OPER(Tj,x) until Ti commits
  or aborts.

14
Time stamp ordering (cont)

• Every data item x has
• TSRD(x) ? max(TS(T i )) where OPER(Ti,x)
  read(Ti,x)
• TSWR(x) ? max(TS(T i )) where OPER(Ti,x)
  write(Ti,x)
• if TS(read(Ti,x)) lt TSWR(x)
• Write on x performed after Tj started
• Then scheduler rejects read(Ti,x), Ti aborted
• TSRD(x) ? max(TS(Ti), TSRD(x))
• if TS(write(Ti,x)) lt TSRD(x)
• Current value of x has been read by a more recent
  Tj
• Then scheduler rejects write(Ti,x), Ti aborted
• TSWR(x) ? max(TS(Ti), TSWR(x))

15
Optimistic Concurrency Control

• Observation
• maintaining locks costs a lot
• in practice not many conflicts.
• Alternative
• Go ahead immediately with all operations
• use tentative writes everywhere (shadow copies)
• solve conflicts later on
• Phases
• allow operations tentatively ? validate effects ?
  make updates permanent.
• Validation Check for each pair of active
  transactions Ti and Tj
• Ti must not read or write data that has been
  written by Tj.
• Tj must not read or write data that has been
  written by Ti.
• If one of the rules doesnt hold abort
  transaction.

16
Comparison

• Locking vs. timestamp ordering
• both are pessimistic
• dynamic vs. static ordering
• write-dominated vs. read-dominated
• Optimistic
• efficient when there are few conflicts
• not widely used

17
Deadlocks

• Definition
• a state in which each member of a group of
  transactions awaits some other member to release
  a lock
• examples
• transactions T and U read the data and both try
  to promote their read lock to write lock
• transaction T waits for transaction U to release
  a lock on a data item A while transaction U waits
  for transaction V to release a lock on a data
  item B and transaction V waits for transaction T
  to release a lock on a data item C
• Wait-for-graphs
• graphical notation to represent wait-for
  relations among transactions

18
Deadlocks (cont)

• Deadlock prevention
• locks all of the data items at the beginning
• hard to predict all the required data items at
  the beginning
• requests locks on data items in a predefined
  order
• may result in premature locking and reduction in
  concurrency
• Deadlock detection
• lock manager checks deadlocks
• whenever a lock request from a transaction is
  given to a data item currently locked by another
  transaction, or
• less frequently to avoid server overhead
• lock manager does the following operations to
  detect a deadlock
• finds a cycle in the wait-for-graph, and
• break the cycle
• once detected, one of transactions in a cycle is
  selected and aborted based on age and of cycles
  it gets involved
• Deadlock resolution
• once detected, one of transactions in a cycle is
  selected and aborted
• timeouts

19
Distributed Deadlocks

• Centralized deadlock detection
• each server sends its local wait-for graph and
  the central deadlock detector checks a cycle by
  global wait-for graphs
• phantom deadlocks
• happens when one of transactions that holds a
  lock (and creates deadlock) will have aborted
  during deadlock detection phase

20
Distributed Deadlocks (cont)

• Distributed deadlock detection
• called edge chasing or path pushing
• no global wait-for graph
• mechanism
• lock manager informs the coordinator when
  transactions start waiting and when they become
  active again
• three phases
• initiation
• if transaction A starts waiting for transaction B
  waiting to access a data item at another server,
  transaction Bs server sends a probe containing
  the wait-for relationship to the server of data
  item where transaction B is blocked and all the
  servers in which transactions share lock with
  transaction B
• detection
• if the data item is hold by another transaction
  (by consulting with coordinator), add this
  relationship to the probe and forward the probe
  in the same manner as above
• resolution
• when cycle is detected, a transaction in a cycle
  is aborted to break the deadlock