Presentation is loading. Please wait.

Presentation is loading. Please wait.

Inconsistent retrieval (is locking enough CC? NO!) 500 800 ________ - |ACCOUNTS| _____ - ' |--------| |AUDIT| >___' | ____ |CHECKING|

Similar presentations


Presentation on theme: "Inconsistent retrieval (is locking enough CC? NO!) 500 800 ________ - |ACCOUNTS| _____ - ' |--------| |AUDIT| >___' | ____ |CHECKING|"— Presentation transcript:

1 Inconsistent retrieval (is locking enough CC? NO!) 500 800 @@@ ________ __/BANK) @ - - @ |ACCOUNTS| _____ | @` - ' |--------| |AUDIT| >___' | ____ |CHECKING| |Ch__ |.|.( )-|100 | |--------| |Sav__|--------|.' | |____| | | |Tot__| (| / `. |--------| ^ /_____`. |SAVINGS | | | L L |________| L L CHECKING SAVINGS T1 write_locks checking XLOCK T1 (transfer) T2 (audit) 1. 500 <- - 500 Xlock 800 T2 reads SAVINGS, then release Slock->800 3. T2 read_locks savings 2. 400 - -> 400 T1 writes, then releases Xlock on CHECKING 400 T2 Slocks CHECKING, reads then then releases Slock->400 4. = 1200 T1 write_locks savings 5. 800 <- - - - - - - - 800 Xlock 6. 900 - - - - - - - -> 900 Xlock released 2. 400 - -> 400 6. 900 - - - - - - - -> 900

2 SOLUTION? 2-Phase Locking (2PL) Each transaction must acquire all its locks before releasing any of its locks. 500 800 @@@ ________ __/BANK) @ - - @ |ACCOUNTS| _____ | @` - ' |--------| |AUDIT| >___' | ____ |CHECKING| |Ch__ |.|.( )-|100 | |--------| |Sav__|--------|.' | |____| | | |Tot__| (| / `. |--------| ^ /_____`. |SAVINGS | | | L L |________| L L CHECKING SAVINGS T1 write_locks checking T1 (transfer) T2 (audit) 1. 500 <- - 500 Xlock 800 Slock - - > 800 3. T2 read_locks savings 2. 400 - -> 400 hold Xlock 400 T2 unable to Slock Checking!! 4. T1 unable to Xlock savings DEADLOCK!!!

3 Is 2PL enough? NO. Uncommited Dependency or Cascading Abort Problem Tammy deposits 500, Jimmy deposits 1000, Tammy's transaction aborts, after Jimmy's commits. Note: In order it accommodate transaction "abort" or "rollback", must use Write-Ahead Logging (WAL): A changed database item cannot be written to the database disk until the "before value" (the value before the change took place) has been "logged" to secure storage (the system log - on a separate disk). Then to rollback a transaction, simply restore all the before values for every item written by that transaction (by searching the log for those before values).

4 Uncommitted Retrieval (or Cascading Rollback) @@@ /// @ - - @ | o o | @ ` ~ ' ` - ' | ____ _____ |.( )---|$500| |$1000|-----|-..' | |____| |_____| ( ) `. / `. ^ /____\ | | L L JOINT L L ACCOUNT T1 (dep $500) BALANCE T2 (dep $1000 workspace of T1 ON DISK workspace of T2 $3500 <- - - - $3500 T2 commits. 4. $2000 1. $2000 <- - $2000 2. add 500: $2500 - -> $2500 $2500 - - - -> $2500 3. (T1 Unlocks account, then T1 swapped out) 5. T1 aborts (terminal gets hung?) before value, $2000 -> $2000

5 2PL solves inconsistent retrieval, but deadlock management is also required. Conservative (C2PL), Strict (S2PL) locks 2PL time locks C2PL time locks S2PL time locks CS2PL time Begin point End (commit/abort) point Acquire phase Release phase Acquire phase Begin point Lock point Release phase End point Acquire phase Release phase End point Acquire phase Begin Release phase End point


Download ppt "Inconsistent retrieval (is locking enough CC? NO!) 500 800 ________ - |ACCOUNTS| _____ - ' |--------| |AUDIT| >___' | ____ |CHECKING|"

Similar presentations


Ads by Google