08_Transactions_LECTURE2 DBMSs should guarantee ACID properties (Atomicity, Consistency, Isolation, Durability). This is typically done by guaranteeing the condition of SERIALIZABLILTY introduced above. - Database operations are scheduled so that changes to the database and output to users is equivalent to the changes and outputs of SOME serial execution. If each transaction is correct by itself (takes a correct database state to another correct state), then a serial sequence of such transactions will be correct also. Thus, serializable executions or histories guarantee correctness. Some important example of "incorrectness" problems, which can happen without proper concurrency control: Allowing arbitrary interleaving of operations from concurrent transactions. (Note: We introduce Two Phase Locking concurrency control as solutions.) Section 8 # 10

Some Problems that must be solved: LOST UPDATE e.g., Tammy deposits 500 while Jimmy deposits 1000 in their joint account. - | o o ` ~ ' ` - ' | ____ _____ |.( )---|$500| |$1000|-----|-..' | |____| |_____| ( ) `. / `. ^ /____\ | | L L JOINT L L ACCOUNT Trans1  deposit $500 BALANCE Trans2  deposit $1000 workspace of Trans1 ON DISK workspace of Trans2 $3000   $ th $ st action: $2000  $ th $2500  $ nd add 500: $2500 $2000   $ th $ th 3 rd Trans1 times is up and is swapped out. Trans2 time is up and is swapped out. 6 th Section 8 # 11

- | 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 < $ $ $2000 <- - $ $ > $ add 500: $2500 $ > $ $ Lost update SOLUTION? LOCKING : Each transaction must obtain a "lock" on an item (access permission from the scheduler) before accessing the item. 0. lock acct - -> 4. unlock acct <- - lock acct 5. unlock acct 5. Section 8 # 12

Concurrent Transactions Concurrent reads (we will call it a read-read) by two transactions, T 1 and T 2, to the same data item, x, can be done in either order (no conflict will exists). If T 1 : read 1 (x) and T 2 : read 2 (x) are concurrent, then in terms of changes to the database (none are made here) and messages to users (2 are made here), the same "effect" is produced regardless of order of execution of read operations, so 2 concurrent reads are not in conflict! Concurrent read-write or write-write to the same data produce different results depending on the order (that is, there is a conflict. a conflict exists iff at least one operation is a write and the operations access the same item). Even if the operations themselves (the individual reads and writes) are made atomic by the Buffer Manager, there can still be "conflict" because different transaction results can occur. So concurrent reads and writes are in conflict! If T 1 : write 1 (x) and T 2 : read 2 (x) are concurrent, then in terms of changes to the database (one is made here) and messages to users (one is made here), different "effects" are produced by the 2 orders of execution of the operations. i.e., if write 1 (x) is done first, T 2 will get the value written to X by T 1, while if write 1 (x) is done second, T 2 gets the initial value of X. If T 1 : write 1 (x) and T 2 : write 2 (x) then in terms of changes to the database (two are made here), different "effects" are produced by the 2 orders of execution of the operations. i.e., if write 1 (x) is done last, the database will be left with the value written by T 1, while if write 2 (x) is done last, database will be left with the value written by T 2. So concurrent writes are in conflict! Section 8 # 13

Concurrent Transactions cont. Therefore, sometimes, to improve performance, we distinguish between locks for read-only access and locks for write-access by having two types of locks: A lock for read-only access is a read-lock or shared-lock (SLOCK). A lock of write-access is a write-lock or exclusive-lock (XLOCK). SLOCKS are "compatible" with each other or "non-conflicting": if an SLOCK is held on a data item, another trans can be granted a concurrent an SLOCK on that item. XLOCKS are "incompatible" or "conflicting": if an XLOCK is held on a data item, another trans cannot be granted a concurrent XLOCK nor a concurrent SLOCK. Therefore the compatibility table is: \Requester> Holder\ > SLOCK | XLOCK vvvvvvvv\________>________________|______ || SLOCK | yes | no | XLOCK | no | no | Both the Compatibility and Conflict tables give the very same information. Sometimes it will be given as a compatibility table and sometimes as a conflict table. Is locking with SLOCKS and XLOCKS enough Concurrency Control? NO! The conflict table is: \Requester> Holder\ > SLOCK | XLOCK vvvvvvvv\________>________________|______ || SLOCK | no | yes | XLOCK | yes | yes | Section 8 # 14

________ - |ACCOUNTS| _____ - ' | | |AUDIT| >___' | ____ |CHECKING| |Ch__ |.|.( )-|100 | | | |Sav__| |.' | |____| | | |Tot__| (| / `. | | ^ /_____`. |SAVINGS | | | L L L L CHECKING SAVINGS T1 write_locks checking XLOCK T1 (transfer) T2 (audit) < Xlock 800 T2 reads SAVINGS, then release Slock-> T2 read_locks savings > 400 T1 writes, then releases Xlock on CHECKING 400 T2 Slocks CHECKING, reads then then releases Slock-> = 1200 T1 write_locks savings < Xlock > 900 Xlock released > > 900 Problems that must be solved: INCONSISTENT RETREIVAL e.g., Tammy transfers $100 from checking to savings, while concurrently the bank is running an audit on the 2 accounts (summing accounts). Is LOCKING ENOUGH CONCURRENCY CONTROL? NO! Section 8 # 15

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

1. Get XLOCK, $2000<-- $ add 500: $ > $ | 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 $ > $ (T1 Unlocks account, then T1 swapped out) 5. T1 aborts (It is discovered that Tammy's 500 bill is counterfeit!). The before value of the balance (before T1 started) is re-installed, $2000 -> $2000 Section 8 # 17 Is 2PL enough Concurrency Control? NO. The Uncommited Dependency or Cascading Abort Problem

A solution to the Uncommited Dependency or Cascading Abort Problem is Strict 2PL or S2PL. Strict 2PL adds that all locks must be held until Commit. Note: In order it accommodate transaction "abort" or "rollback" by re- intalling before values, the system 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). Another solution to the Uncommitted Dependency problem is Conservative 2PL or C2PL, in which, all locks must be obtained at BEGIN. All of these combinations are shown on the next slide. Section 8 # 18

Conservative2PL (C2PL) or Strict2PL (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 Section 8 # 19

Deadlock Management Deadlocks can occur when a WAITING POLICY is used for CC. How can deadlocks be PREVENTED (precluding the possibly of one ever happening), AVOIDED (taking corrective action when one is imminent) or RESOLVED (detecting existing deadlocks and resolving them (periodically)? First, a useful tool for studying deadlock mgmt is the WAIT-FOR-GRAPH or WFG which has a node for each transaction that is involved in a wait an edge from each waiting transaction (the holder) to the transaction it is waiting for (requester). The WFG in the 2PL example above. Formal Definition: A DEADLOCK is a cycle in the Wait-For-Graph. It is sometimes useful to label edges with item involved This is called a binary cycle (2 transactions) T1T1 T2T2 T1T1 T2T2 savings checking Section 8 # 20