Databases: Locking Methods

5,864 views
5,582 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,864
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
95
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Databases: Locking Methods

  1. 1. Locking Methods
  2. 2. Locking Methods <ul><li>These are the most widely used methods </li></ul><ul><li>A transaction much claim a READ (SHARED) or WRITE (EXCLUSIVE) lock on a data item prior to execution of the corresponding write/read of that item </li></ul><ul><li>more than one lock can hold read lock on the same data item </li></ul>
  3. 3. Granularity of Locks <ul><li>Database (Relation) </li></ul><ul><li>Record (Tuple-level) </li></ul><ul><li>Data Item (Attribute level) </li></ul><ul><li>to maximise concurrency </li></ul><ul><ul><li>best level is tuple-level </li></ul></ul>
  4. 4. Two-Phase Locking <ul><li>So-called because the process works in two phases, in phase one, the transaction acquires locks, in phase two the transaction releases locks. </li></ul><ul><li>In most systems phase two is put off for as long as possible, until the very end (commit / rollback). </li></ul>
  5. 5. Locking Problems <ul><li>Deadlock </li></ul><ul><li>A deadlock is a situation in which two computer programs sharing the same resource are effectively preventing each other from accessing the resource, resulting in both programs ceasing to function. </li></ul>
  6. 6. Locking Problems <ul><li>Livelock </li></ul><ul><li>When two or more processes continuously change their state in response to changes in the other process(es) without doing any useful work. </li></ul>
  7. 7. Deadlock Prevention Protocol <ul><li>Avoid the overhead of deadlock detection </li></ul><ul><li>Avoid the overhead of deadlock occuring </li></ul><ul><li>Order Locks </li></ul><ul><li>Order Transaction (take a ticket) </li></ul>
  8. 8. Timestamp Methods <ul><li>Not necessarily time of the computer system clock, could be just an incrementing counter as a locking mechanism </li></ul><ul><li>Two methods </li></ul><ul><ul><li>wait-die </li></ul></ul><ul><ul><li>wound-wait </li></ul></ul>
  9. 9. Wait-die <ul><li>Begin </li></ul><ul><li>T1 requests lock on item held by T2 </li></ul><ul><li>if T1 is older than T2 </li></ul><ul><li>then T1 waits until T2 (is commit/rolled) </li></ul><ul><li>else T1 is rolled back </li></ul><ul><li>end if </li></ul><ul><li>End </li></ul>
  10. 10. Wound-wait <ul><li>Begin </li></ul><ul><li>T1 requests lock on item held by T2 </li></ul><ul><li>if T1 is older than T2 </li></ul><ul><li>then T2 is rolled back </li></ul><ul><li>else T1 waits for T2 (to commit/rollback) </li></ul><ul><li>end if </li></ul><ul><li>End </li></ul>
  11. 11. Optimistic Methods <ul><li>Transaction goes all the way to commit and then checks for conflicts </li></ul><ul><li>Transactions are executed in three phases : </li></ul><ul><ul><li>Read Phase </li></ul></ul><ul><ul><li>Validation Phases </li></ul></ul><ul><ul><li>Write Phase </li></ul></ul>
  12. 12. Stages of a transaction <ul><ul><li>Read Phase : this is the body of the transaction up to commit </li></ul></ul><ul><ul><li>Validation Phase : the results of the transaction are examined for conflicts </li></ul></ul><ul><ul><li>Write Phase : if the transaction is validated then the updates are propagated, if conflict was detected then the transaction is rolled back and restarted </li></ul></ul>

×