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 UPDATEe.g., Tammy deposits 500 while Jimmy deposits 1000 in their joint account.

@@@ /// @ - - @ | o o | @ ` ~ ' ` - ' | ____ _____ | .( )---|$500| |$1000|-----|-. .' | |____| |_____| ( ) `. / `. ^ /____\ | | L L JOINT L L ACCOUNT Trans1deposit $500 BALANCE Trans2deposit $1000 workspace of Trans1 ON DISK workspace of Trans2

$3000 $3000 8th

$2000

1st action: $2000 $2000

7th $2500 $2500

2nd add 500: $2500

$2000 $2000 4th

$3000 1000++ 5th

3rd Trans1 times is up and is swapped out.

Trans2 time is up and is swapped out. 6th

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 <- - - - $3500 8.

$2000

1. $2000 <- - $2000

3. $2500 - -> $2500

2. add 500: $2500

$2500 - - - -> $2500 6.

$3000 1000++ 7.

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, T1 and T2, to the same data item, x,

can be done in either order (no conflict will exists).

If T1: read1(x) and T2: read2(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 T1: write1(x) and T2: read2(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 write1(x) is done first, T2 will get the value written to X by T1, while if write1(x) is done second, T2 gets the initial value of X.

If T1: write1(x) and T2: write2(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 write1(x) is done last, the database will be left with the value written by T1, while if write2(x) is done last, database will be left with the value written by T2. 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

500 800

@@@ ________ __/BANK) @ - - @ |ACCOUNTS| _____ < $> | @` - ' |--------| |AUDIT| >___' | ____ |CHECKING| |Ch__ | .| .( )-|100 | |--------| |Sav__|--------| .' | |____| | | |Tot__| (| / `. |--------| ^ /_____`. |SAVINGS | | | L L L L CHECKING SAVINGS

T1 write_locks checking XLOCKT1 (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

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).

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!!! Section 8 # 16

1. Get XLOCK, $2000<-- $20002. add 500: $2500 - -> $2500

@@@ /// @ - - @ | 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

$2500 - - - -> $2500 3.

(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 pointSection 8 # 19

Deadlock ManagementDeadlocks 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)

T1 T2

T1 T2

savings

checking

Section 8 # 20