1. Chapter 16 Concurrency

2. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-2 Topics in this Chapter Three Concurrency Problems Locking Deadlock Serializability Isolation Levels Intent Locking Dropping ACID SQL Facilities

3. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-3 Three Concurrency Problems In a multi-processing environment transactions can interfere with each other Three concurrency problems can arise, that any DBMS must account for and avoid: Lost Updates Uncommitted Dependency Inconsistent Analysis

4. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-4 Three Concurrency Problems – Description A lost update occurs when a second transaction reads the state of the database prior to the first one writing a change, and then stomps on the first one’s change with its own update An uncommitted dependency occurs when a second transaction relies on a change which has not yet been committed, which is rolled back after the second transaction has begun An inconsistent analysis occurs when totals are calculated during interleaved updates

5. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-5 Conflicts A RW (read write) conflict occurs when writes are interspersed with reads (inconsistent analysis) A WR conflict, or dirty read, occurs when the reader is relying on uncommitted writes A WW conflict, or dirty write, occurs when the second writer never accounted for the first one (lost update)

6. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-6 Locking A transaction locks a portion of the database to prevent concurrency problems Exclusive lock – write lock, will lock out all other transactions Shared lock – read lock, will lock out writes, but allow other reads

7. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-7 Strict Two-Phase Locking A second transaction, if locked out by the first, goes into a wait state First come, first served will make sure the second one is next when the first releases the lock, to avoid livelock, a/k/a starvation Once the first transaction issues a COMMIT or ROLLBACK, the second one takes its lock

8. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-8 Deadlock Strict two-phase locking may result in deadlock if two transactions each take a shared lock before one of them tries to take an exclusive lock Or if the second one tries to take an exclusive lock where the first already has a shared lock, and the first in turn is waiting for additional shared locks

9. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-9 Deadlock Solutions The DBMS may detect a deadlock, or detect a lack of progress, and roll back a “victim” The locking protocol may be modified to avoid deadlock by using Wait-Die and Wound-Wait Wait-Die: Transaction 2 waits if it is older than 1; otherwise it dies Wound-Wait: Transaction 2 wounds 1 if it is older; that is, it rolls it back Net effect: oldest transaction wins

10. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-10 Serializability An interleaved execution is considered correct if and only if it is serializable A set of transactions is serializable if and only if it is guaranteed to produce the same result as when each transaction is completed prior to the following one being started If all transactions obey two phase locking, then all possible interleaved schedules are serializable

11. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-11 Recovery Redux Interleaved transactions can suffer from uncommitted dependency during recovery If a first transaction attempts to roll back after a second one commits, the schedule could be unrecoverable The danger of unlimited rollback of interleaved transactions is that it could cascade indefinitely The second transaction must wait until the first commits before terminating

12. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-12 Isolation Levels In the ideal world of isolation, a transaction completes before another begins In the real world, isolation has levels The higher the level of isolation, the less interference, and the greater concurrency Cursor stability permits shared locks for reading, that are released before the transaction completes Repeatable read ensures that a read is repeatable throughout the transaction

13. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-13 Phantoms Under two phase locking, inconsistent analysis can still occur if locks are released prior to the analysis being complete An interleaved update can create a phantom The solution is to lock the predicate for the duration of the transaction Most systems cannot lock the predicate, so they lock the access path

14. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-14 Intent Locking Locking granularity: locks can be taken at the tuple level, or by relvar, database, or attribute To avoid examining every tuple to determine if any are locked, the intent locking protocol declares a lock at the relvar to forecast conflicts Modes are intent shared, intent exclusive and shared intent exclusive

15. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-15 Intent Locking – Shared and Exclusive Before a given transaction can acquire a shared lock on a given tuple, it must first acquire an intent shared or stronger lock on the relvar containing the tuple Before a given transaction can acquire an exclusive lock on a given tuple, it must first acquire an intent exclusive lock on the relvar containing the tuple For shared intent exclusive, a transaction can tolerate other readers, but not other updaters, and reserves the right to take a lock to update

16. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-16 Dropping ACID ACID requires checking constraints at the end of the transaction Mr. Date believes constraints must be checked immediately The integrity of the predicate, and concomitant truth of the propositions, must be maintained throughout the transaction, rather than merely certified at the end This principle requires a multiple assignment operator

17. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-17 Dropping ACID, One Piece at a Time Consistency is trivial, and correctness unenforceable: the “C” is meaningless Isolation requires serial execution; in the real world it is a target imperfectly attained, and so doesn’t really exist Durability is relative: when the second transaction completes before the first, it may have to be rolled back Atomicity should be a property of statements rather than transactions

18. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.16-18 SQL Facilities READ UNCOMMITTED: permits dirty reads, nonrepeatable reads, phantoms READ COMMITTED: permits nonrepeatable reads and phantoms, but prohibits dirty reads REPEATABLE READ: permits phantoms, but not dirty reads, nor nonrepeatable reads SERIALIZABLE: true two phase locking, it keeps all transactions serializable