Concurrency Control for Transactions Part One Notes | EduRev

: Concurrency Control for Transactions Part One Notes | EduRev

 Page 1


1/11/2012 
1 
3. Concurrency Control 
for Transactions 
Part One 
 CSEP 545 Transaction Processing 
Philip A. Bernstein 
 
Copyright ©2012 Philip A. Bernstein 
Page 2


1/11/2012 
1 
3. Concurrency Control 
for Transactions 
Part One 
 CSEP 545 Transaction Processing 
Philip A. Bernstein 
 
Copyright ©2012 Philip A. Bernstein 
1/11/2012 
2 
Outline 
1. A Simple System Model 
2. Serializability Theory 
3. Synchronization Requirements  
    for Recoverability 
4. Two-Phase Locking 
5. Preserving Transaction Handshakes 
6. Implementing Two-Phase Locking 
7. Deadlocks 
Page 3


1/11/2012 
1 
3. Concurrency Control 
for Transactions 
Part One 
 CSEP 545 Transaction Processing 
Philip A. Bernstein 
 
Copyright ©2012 Philip A. Bernstein 
1/11/2012 
2 
Outline 
1. A Simple System Model 
2. Serializability Theory 
3. Synchronization Requirements  
    for Recoverability 
4. Two-Phase Locking 
5. Preserving Transaction Handshakes 
6. Implementing Two-Phase Locking 
7. Deadlocks 
1/11/2012 
3 
3.1 A Simple System Model 
• Goal - Ensure serializable (SR) executions 
• Implementation technique - Delay operations 
that may lead to non-SR results (e.g. set locks 
on shared data) 
• For good performance minimize overhead and 
delay from synchronization operations 
• First, we’ll study how to get correct (SR) results 
• Then, we’ll study performance implications 
(mostly in Part Two) 
Page 4


1/11/2012 
1 
3. Concurrency Control 
for Transactions 
Part One 
 CSEP 545 Transaction Processing 
Philip A. Bernstein 
 
Copyright ©2012 Philip A. Bernstein 
1/11/2012 
2 
Outline 
1. A Simple System Model 
2. Serializability Theory 
3. Synchronization Requirements  
    for Recoverability 
4. Two-Phase Locking 
5. Preserving Transaction Handshakes 
6. Implementing Two-Phase Locking 
7. Deadlocks 
1/11/2012 
3 
3.1 A Simple System Model 
• Goal - Ensure serializable (SR) executions 
• Implementation technique - Delay operations 
that may lead to non-SR results (e.g. set locks 
on shared data) 
• For good performance minimize overhead and 
delay from synchronization operations 
• First, we’ll study how to get correct (SR) results 
• Then, we’ll study performance implications 
(mostly in Part Two) 
1/11/2012 
4 
Assumption - Atomic Operations 
• We will synchronize Reads and Writes. 
• We must therefore assume they’re atomic 
– else we’d have to synchronize the finer-grained 
operations that implement Read and Write 
• Read(x) - returns the current value of x in the DB 
• Write(x, val) overwrites all of x (the whole page) 
• This assumption of atomic operations allows us 
to abstract executions as sequences of reads and 
writes (without loss of information). 
– Otherwise, what would w
k
[x] r
i
[x] mean? 
• Also, commit (c
i
) and abort (a
i
) are atomic 
Page 5


1/11/2012 
1 
3. Concurrency Control 
for Transactions 
Part One 
 CSEP 545 Transaction Processing 
Philip A. Bernstein 
 
Copyright ©2012 Philip A. Bernstein 
1/11/2012 
2 
Outline 
1. A Simple System Model 
2. Serializability Theory 
3. Synchronization Requirements  
    for Recoverability 
4. Two-Phase Locking 
5. Preserving Transaction Handshakes 
6. Implementing Two-Phase Locking 
7. Deadlocks 
1/11/2012 
3 
3.1 A Simple System Model 
• Goal - Ensure serializable (SR) executions 
• Implementation technique - Delay operations 
that may lead to non-SR results (e.g. set locks 
on shared data) 
• For good performance minimize overhead and 
delay from synchronization operations 
• First, we’ll study how to get correct (SR) results 
• Then, we’ll study performance implications 
(mostly in Part Two) 
1/11/2012 
4 
Assumption - Atomic Operations 
• We will synchronize Reads and Writes. 
• We must therefore assume they’re atomic 
– else we’d have to synchronize the finer-grained 
operations that implement Read and Write 
• Read(x) - returns the current value of x in the DB 
• Write(x, val) overwrites all of x (the whole page) 
• This assumption of atomic operations allows us 
to abstract executions as sequences of reads and 
writes (without loss of information). 
– Otherwise, what would w
k
[x] r
i
[x] mean? 
• Also, commit (c
i
) and abort (a
i
) are atomic 
1/11/2012 
5 
System Model 
Transaction 1 Transaction N 
Start, Commit, Abort 
  Read(x), Write(x) 
Data 
Manager 
Database 
Transaction 2 
Read More
Offer running on EduRev: Apply code STAYHOME200 to get INR 200 off on our premium plan EduRev Infinity!