Distributed Systems
Concurrency Control
Paul Krzyzanowski
[email protected]
[email protected]
Except as otherwise noted, the content of this presentation is licensed under the Creative Commons
Attribution 2.5 License.
Page 1
Schedules
• Transactions must have scheduled so that data is
serially equivalent
• Use mutual exclusion to ensure that only one
transaction executes at a time
• or…
• Allow multiple transactions to execute
concurrently
– but ensure serializability
• concurrency control
• schedule: valid order of interleaving
Page 2
Locking
• Serialize with exclusive locks on a resource
– lock data that is used by the transaction
– lock manager
• Conflicting operations of two transactions
must be executed in the same order
– transaction not allowed new locks after it has
released a lock
• Two-phase locking
– phase 1: growing phase: acquire locks
– phase 2: shrinking phase: release locks
Page 3
Strict two-phase locking
• If a transaction aborts
– any other transactions that have accessed data
from released locks (uncommitted data) have to be
aborted
– cascading aborts
• Avoid this situation:
– transaction holds all locks until it commits or
aborts
• strict two-phase locking
Page 4
Locking granularity
• Typically there will be many objects in a
system
– a typical transaction will access only a few of them
(and is unlikely to clash with other transactions)
• Granularity of locking affects concurrency
– smaller amount locked higher concurrency
Page 5
Multiple readers/single writer
Improve concurrency by supporting multiple
readers
– there is no problem with multiple transactions
reading data from the same object
– only one transaction should be able to write to an
object … and no other transactions should read in
this case
Page 6
Multiple readers/single writer
Two locks: read locks and write locks
– set a read lock before doing a read on an object
– set a write lock before doing a write on an object
– block (wait) if transaction cannot get the lock
If a transaction has:
– no locks for an object: another transaction may obtain a read
or write lock
– a read lock for an object: another transaction may obtain a
read but wait for write lock
– a write lock for an object: another transaction will have to
wait for a read or a write lock
Page 7
Increasing concurrency: two-version locking
• Transaction can write tentative versions of objects
– others read from the committed (original) version
• Read operations wait if another transaction is
committing the same object
• Allows for more concurrency than read-write locks
– writing transactions risk waiting or rejection when they
attempt to commit
– transactions cannot commit if other uncompleted
transactions have read the objects
– these transactions must wait until the reading transactions
have committed
Page 8
Two-version locking
Three types of locks:
– read lock, write lock, commit lock
Transaction cannot get a read or write lock if
there is a commit lock
Page 9
Two-version locking
When the transaction coordinator receives a request to
commit:
– converts all that transaction’s write locks into commit locks
– If any objects have outstanding read locks, transaction must
wait until the transactions that set these locks have
completed and locks are released
Compare with read/write locks:
– read operations delayed only while transactions are
committed
– read operations of one transaction can cause delay in the
committing of other transactions
Page 10
Problems with locking
• Locks have an overhead: maintenance,
checking
• Locks can result in deadlock
• Locks may reduce concurrency by having
transactions hold the locks until the
transaction commits (strict two-phase
locking)
Page 11
Optimistic concurrency control
• In most applications the chance of two
transactions accessing the same object is low
• Allow transactions to proceed without
obtaining locks
• Check for conflicts at commit time
– if there is a conflict abort and restart some
transaction
• Phases:
– working phase
– validation phase
– update phase
Page 12
Timestamp ordering
• Assign unique timestamp to a transaction when it
begins
• Each object has a read and write timestamp
associated with it
– which committed transaction last read the object
– which committed transaction last wrote the object
• Good ordering:
– object’s read and write timestamps will be older than current
transaction if it wants to write an object
– object’s write timestamps will be older than current
transaction if it wants to read an object
• Abort and restart transaction for improper ordering
Page 13
The end.
Page 14
