Transaction processing Book, chapter 6.6

Problem: With a single user…. you run a query, you get the results, you run the next, etc. But database life is rarely that simple. Multi user systems where users can be accessing data at the same time.

Protecting the database Recovery – restoring the database to a correct state after a failure Concurrency control – allow simultaneous use without unwanted interference

Passenger 1 Opens seat assignment query Seat 13 C shows as available Thinks Takes a phone call Select 13 C update query Passenger 2 Opens seat assignment query Sees Seat 13 C as available Select 13C update query Who gets the seat?

Transaction “a group of operations that need to be performed together” Serializability – The property that a transaction with respect to other transactions must appear to be run in serial (one after another)…or in other words, one transaction completes before the next can begin.

In the prior case If Passenger 1 and 2 are both shown the seat, passenger 2 chooses it first, passenger 1 should not be allowed to complete his/her transaction. If passenger 1 is told, “I’m sorry, but that seat is now taken” and the choice is blocked, passenger 1 will need to make another choice and more importantly, the database is left in a consistent state.

Options We could block passenger 2 from seeing anything until passenger 1 is done (phone call) We could display both, but not let P2 make a choice until P1 is done We could let P2 make a choice and then alert P1 that their choice failed We could let P1’s choice go through and negate P2’s

Atomicity A transaction is considered an atomic statement – it is an all or nothing proposition. Another example

Banking example Customer transfers money Check account 1 Deduct from account 1 Credit account 2 What if the last bit doesn’t go through?

Transaction One or more statements that must execute as a group. START TRANSACTION  begins a group of statements COMMIT  tells the system to make the transaction permanent (everything is ok) ROLLBACK  tells the system to go back to the original state (problem)

Properties A – Atomic C – Consistent I – Isolated D - Durable

Problems Lost update problem – See airline example Uncommitted update problem – One transaction “looks at” a change, but the change never goes through because of a problem; it’s result is based on wrong information. Inconsistent analysis – Query once, query a second time after data has changed

Problems Non repeatable read 1 reads 2 changes 1 reads again and its different Phantom transaction 1 reads 2 inserts 1 reads again and now new row

No problem 2 Transactions may read data at the same time 2 Transactions may operate on completely different data elements 2 Transactions operate on the same data set in serial time

Serial process Transaction 1 Transaction 2 Transaction 3 Transaction 4

Interleaved process Transaction 1A Transaction 2A Transaction 1B Transaction 2B

Preventing concurrency issues Locking – halt operation of one transaction while the resource required is in use Timestamping – transactions are stamped with a start time and checked against the resource change time.