DOC PREVIEW
UMD CMSC 424 - Lecture 22 Concurrency/recovery

This preview shows page 1-2-22-23 out of 23 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CMSC 424 – Database designLecture 22Concurrency/recoveryMihai PopAdmin•Signup sheet for project presentationsRecap...1•ACID properties:–Atomicity (recovery)–Consistency (transaction design, , concurrency control, recovery)–Isolation (concurrency control)–Durability (recovery)Recap•Concurrency Control Scheme–A way to guarantee serializability, recoverability etc•Lock-based protocols–Use locks to prevent multiple transactions accessing the same data items•2 Phase Locking–Locks acquired during growing phase, released during shrinking phase•Strict 2PL, Rigorous 2PLMore Locking Issues: Deadlocks•No xction proceeds:Deadlock- T1 waits for T2 to unlock A- T2 waits for T1 to unlock Block-S(A)read(A)lock-S(B)lock-X(B)read(B)B  B-50write(B) lock-X(A)T2T1Rollback transactionsCan be costly...2PL and Deadlocks•2PL does not prevent deadlock–Strict doesn’t either•> 2 xctions involved?- Rollbacks expensivelock-S(A)read(A)lock-S(B)lock-X(B)read(B)B  B-50write(B) lock-X(A)T2T1Preventing deadlocks•Solution 1: A transaction must acquire all locks before it begins–Not acceptable in most cases•Solution 2: A transaction must acquire locks in a particular order over the data items–Also called graph-based protocols•Solution 3: Use time-stamps; say T1 is older than T2–wait-die scheme: T1 will wait for T2. T2 will not wait for T1; instead it will abort and restart–wound-wait scheme: T1 will wound T2 (force it to abort) if it needs a lock that T2 currently has; T2 will wait for T1.•Solution 4: Timeout based–Transaction waits a certain time for a lock; aborts if it doesn’t get it by thenDeadlock detection and recovery•Instead of trying to prevent deadlocks, let them happen and deal with them if they happen•How do you detect a deadlock?–Wait-for graph–Directed edge from Ti to Tj•Ti waiting for TjX(W)X(Z)S(V)X(V)S(W)S(V)T4T3T2T1T1T2T4T3Suppose T4 requests lock-S(Z)....Dealing with Deadlocks•Deadlock detected, now what ?–Will need to abort some transaction–Prefer to abort the one with the minimum work done so far–Possibility of starvation•If a transaction is aborted too many times, it may be given priority in continuingLocking granularity•Locking granularity–What are we taking locks on ? Tables, tuples, attributes ?•Coarse granularity–e.g. take locks on tables–less overhead (the number of tables is not that high)–very low concurrency•Fine granularity–e.g. take locks on tuples–much higher overhead–much higher concurrency–What if I want to lock 90% of the tuples of a table ?•Prefer to lock the whole table in that caseGranularity Hierarchy The highest level in the example hierarchy is the entire database. The levels below are of type area, file or relation and record in that order. Can lock at any level in the hierarchyGranularity Hierarchy•New lock mode, called intentional locks–Declare an intention to lock parts of the subtree below a node–IS: intention shared•The lower levels below may be locked in the shared mode–IX: intention exclusive–SIX: shared and intention-exclusive•The entire subtree is locked in the shared mode, but I might also want to get exclusive locks on the nodes below•Protocol:–If you want to acquire a lock on a data item, all the ancestors must be locked as well, at least in the intentional mode –So you always start at the top root nodeGranularity Hierarchy(1) Want to lock F_a in shared mode, DB and A1 must be locked in at least IS mode (but IX, SIX, S, X are okay too)(2) Want to lock rc1 in exclusive mode, DB, A2,Fc must be locked in at least IX mode (SIX, X are okay too)Parent Child can belocked in locked inISIXSSIXXPCIS, SIS, S, IX, X, SIX[S, IS] not necessaryX, IX, [SIX]noneGranularity HierarchyCompatibility Matrix with Intention Lock Modes•The compatibility matrix (which locks can be present simultaneously on the same data item) for all lock modes is: ISIXSS IXX ISIXSS IXX ×  ××× × × ××× ×× ×××××holderrequestorExampleR1t1t2 t3t4T1(IS)T1(S), T2(IX)T2(X)ExamplesRt1t3t4t2f2.1f2.2f4.2f4.2T1(IX)T1(IX)T1(X)Rt1t3t4t2f2.1f2.2f4.2f4.2T1(IS)T1(S)Rt1t3t4t2f2.1f2.2f4.2f4.2T1(SIX)T1(IX)T1(X)Can T2 access object f2.2 in X mode? What locks will T2 get?Examples•T1 scans R, and updates a few tuples:–T1 gets an SIX lock on R, then repeatedly gets an S lock on tuples of R, and occasionally upgrades to X on the tuples.•T2 uses an index to read only part of R:–T2 gets an IS lock on R, and repeatedly gets an S lock on tuples of R.•T3 reads all of R:–T3 gets an S lock on R. –OR, T3 could behave like T2; can use lock escalation to decide which.--IS IX--ISIX√√√√ √√S X√√SX√ √√√√√ √√Recap, Next….•Deadlocks–Detection, prevention, recovery•Locking granularity–Arranged in a hierarchy–Intentional locks•Next…–Brief discussion of some other concurrency schemesOther CC Schemes•Time-stamp based–Transactions are issued time-stamps when they enter the system–The time-stamps determine the serializability order–So if T1 entered before T2, then T1 should be before T2 in the serializability order–Say timestamp(T1) < timestamp(T2)–If T1 wants to read data item A•If any transaction with larger time-stamp wrote that data item, then this operation is not permitted, and T1 is aborted–If T1 wants to write data item A•If a transaction with larger time-stamp already read that data item or written it, then the write is rejected and T1 is aborted–Aborted transaction are restarted with a new timestamp•Possibility of starvationOther CC Schemes•Time-stamp based–As discussed here, has too many problems•Starvation•Non-recoverable•Cascading rollbacks required–Most can be solved fairly easily•Read up–Remember: We can always put more and more restrictions on what the transactions can do to ensure these things•The goal is to find the minimal set of restrictions to as to not hinder concurrencyOther CC Schemes•Optimistic concurrency control–Also called validation-based –Intuition •Let the transactions execute as they wish•At the very end when they are about to commit, check if there might be any problems/conflicts etc–If no, let it commit–If yes, abort and restart–Optimistic: The hope is that there won’t be too many problems/aborts•Rarely used any moreThe “Phantom” problem•An interesting problem that comes up for dynamic databases•Schema:


View Full Document

UMD CMSC 424 - Lecture 22 Concurrency/recovery

Documents in this Course
Lecture 2

Lecture 2

36 pages

Databases

Databases

44 pages

Load more
Download Lecture 22 Concurrency/recovery
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 22 Concurrency/recovery and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 22 Concurrency/recovery 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?