MSc IT UFCE8K-15-M Data Management Prakash Chatterjee Room 2Q Lecture 8 : Transactions & Concurrency

UFIE8K-15-M Data Management 2013/142 Transactions ‘Transaction’ in a DBMS means an elemental unit of work which is either completed in full or fails totally DB Transactions are not the same as a user transaction such as ‘place an order’ Each transaction has begin transaction some work - reads and writes to the db either COMMIT (make changes permanent) or ROLLBACK (destroy all evidence of work)

UFIE8K-15-M Data Management 2013/143 ACID (A) Atomicity Transaction is indivisible unit of work - can’t partly succeed (C) Consistency Transaction (failed or completed) must leave DB in a consistant state (I) Isolation Each transaction must appear to run in isolation to any other transactions (D) Durability Work done must be permanent

UFIE8K-15-M Data Management 2013/144 Implementing ACID (A) Atomicity system must be able to undo work if transaction fails - e.g. due to failed integrity constraint system could record the before state of an record and restore these when rollback required (C) Consistency fail if an integrity or transaction constraint violated (I) Isolation concurrency problem >> (D) Durability DB backup and recovery, transaction logging

UFIE8K-15-M Data Management 2013/145 Concurrency Control If transactions could be serialised - executed one at a time - each would execute in Isolation but this would slow the system down - most of the time is spent waiting for disk access If not prevented, interaction between transactions can cause anomalies

UFIE8K-15-M Data Management 2013/146 Lost Update T1 bot read(x) x=x+1 write(x) commit if x=2 at start, it should be 4 at end T2 bot read(x) x=x+1 write(x) commit but its only 3!

UFIE8K-15-M Data Management 2013/147 Dirty Read T1 bot read(x) x=x+1 write(x) abort x should be 3 T2 bot read(x) x=x+1 write(x) commit but it is 4!

UFIE8K-15-M Data Management 2013/148 Inconsistent Read T1 bot read(x) commit T1 sees different values of x during its execution T2 bot read(x) x=x+1 write(x) commit

UFIE8K-15-M Data Management 2013/149 Ghost update x+y must = 100 T1 bot read(y) read(x) ? x+y=90 commit T2 bot read(y) read(x) x=x -10 write(x) y=y+10 write(y) commit now x+y = 100 again

UFIE8K-15-M Data Management 2013/1410 Scheduling A schedule is a sequence of operations (reads or writes) from multiple transactions Reads and writes are assumed to be atomic themselves The Scheduler tries to create a schedule which preserves Isolation Serial schedule puts one transaction after another, but this will be inefficient Need to find equivalent, shorter schedules

UFIE8K-15-M Data Management 2013/1411 Pessimistic/Optimistic Pessimistic assume transactions will interact and prevent it Locking Timestamping Optimistic assume transactions will NOT interact but take action if they do

UFIE8K-15-M Data Management 2013/1412 Locking Read lock (shared lock) any number can read but no one can write readers need counting Write lock (exclusive lock) no one else can read or write Unlock - drop the lock Transaction waits if resource already locked Locks held in DB - lock table Lock granularity best if only a record is locked but lock table large

UFIE8K-15-M Data Management Two-phase locking Discipline on transactions to ensure schedule is serialiable Growing phase: Transaction must acquire all its locks in one phase Lock level can be escalated ( read > write) Shrinking phase Transaction must release all its locks in the second phase Lock level can reduce (write > read) Can’t acquire a lock after releasing a lock

UFIE8K-15-M Data Management 2013/1414 Lost Update with Locking T1 bot wlock(x) read(x) x=x+1 write(x) unlock(x) commit T2 bot wlock(x) wait read(x) x=x+1 write(x) commit

UFIE8K-15-M Data Management 2013/1415 Dirty Read with locking T1 bot wlock(x) read(x) x=x+1 write(x) unlock(x) abort x should be 3 but it is still 4 ! T2 bot wlock(x) wait read(x) x=x+1 write(x) unlock(x) commit

UFIE8K-15-M Data Management 2013/1416 Strict Two-phase locking Locks can only be released after commit Deadlock T1 wlocks(x) and waits to wlock(y) T2 wlocks(y) and waits to wlock(x)

UFIE8K-15-M Data Management 2013/1417 Deadlock T1 wlocks(x) and waits to wlock(y) T2 wlocks(y) and waits to wlock(x) Approaches timeout - lock expires so transaction aborts deadlock detection - identifying deadlocks and killing one transaction