Page 1
Page 1
Concurrency Control
Paul Krzyzanowski
pxk@cs.rutgers.edu
ds@pk.org
Distributed Systems
Except as otherwise noted, the content of this presentation is licensed under the Creative CommonsAttribution 2.5 License.
Page 2
Schedules
•Transactions must have scheduled so thatdata is serially equivalent
•Use mutual exclusion to ensure that only onetransaction executes at a time
•or…
•Allow multiple transactions to executeconcurrently
–but ensure serializability
•concurrency control
•schedule: valid order of interleaving
Page 3
Locking
•Serialize with exclusive locks on a resource
–lock data that is used by the transaction
–lock manager
•Conflicting operations of two transactionsmust be executed in the same order
–transaction not allowed new locks after it hasreleased a lock
•Two-phase locking
–phase 1: growing phase: acquire locks
–phase 2: shrinking phase: release locks
Page 4
Strict two-phase locking
•If a transaction aborts
–any other transactions that have accessed datafrom released locks (uncommitted data) have to beaborted
–cascading aborts
•Avoid this situation:
–transaction holds all locks until it commits oraborts
•strict two-phase locking
Page 5
Locking granularity
•Typically there will be many objects in asystem
–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 6
Multiple readers/single writer
Improve concurrency by supporting multiplereaders
–there is no problem with multiple transactionsreading data from the same object
–only one transaction should be able to write to anobject … and no other transactions should read inthis case
Page 7
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 reador write lock
–a read lock for an object: another transaction may obtain aread but wait for write lock
–a write lock for an object: another transaction will have towait for a read or a write lock
Page 8
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 iscommitting the same object
•Allows for more concurrency than read-write locks
–writing transactions risk waiting or rejection when theyattempt to commit
–transactions cannot commit if other uncompletedtransactions have read the objects
–these transactions must wait until the reading transactionshave committed
Page 9
Two-version locking
Three types of locks:
–read lock, write lock, commit lock
Transaction cannot get a read or write lock ifthere is a commit lock
Page 10
Two-version locking
When the transaction coordinator receives a request tocommit:
–converts all that transaction’s write locks into commit locks
–If any objects have outstanding read locks, transaction mustwait until the transactions that set these locks havecompleted and locks are released
Compare with read/write locks:
–read operations delayed only while transactions arecommitted
–read operations of one transaction can cause delay in thecommitting of other transactions
Page 11
Problems with locking
•Locks have an overhead: maintenance,checking
•Locks can result in deadlock
•Locks may reduce concurrency by havingtransactions hold the locks until thetransaction commits (strict two-phaselocking)
Page 12
Optimistic concurrency control
•In most applications the chance of twotransactions accessing the same object is low
•Allow transactions to proceed withoutobtaining locks
•Check for conflicts at commit time
–if there is a conflict abort and restart sometransaction
•Phases:
–working phase
–validation phase
–update phase
Page 13
Timestamp ordering
•Assign unique timestamp to a transaction when itbegins
•Each object has a read and write timestampassociated 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 currenttransaction if it wants to write an object
–object’s write timestamps will be older than currenttransaction if it wants to read an object
•Abort and restart transaction for improper ordering
Page 14
Page 14
The end.