1. The Relational Model1 Transaction Processing Units of Work

2. The Relational Model2 Transaction Processing Important idea Complex and difficult technology to build Consequences for Safety Reliability Efficiency We don’t have to build it We must learn to use it

3. The Relational Model3 The unit of work Selling something 1) CustomerBill = CustomerBill + Cost 2) SalesCom = SaleCom + (Cost * 0.05) 3) Stock = Stock -1 4) Create Order What if the system fails after 3? What if the stock was already zero

4. The Relational Model4 All or nothing We want: transaction to be completed or, failing that nothing to be done May involve undoing earlier things We speak of “atomic” actions

5. The Relational Model5 ACID properties Atomicity All or nothing Responsibility of DBMS Consistency DB goes from one consistent state to another Responsibility of DBMS and app. Programmer Isolation Partial effect of one not seen by others Responsibility of DBMS (concurrency subsystem) Durability Effects must be permanently stored Responsibility of the DBMS (recovery subsystem)

6. The Relational Model6 Form of a transaction Begin Transaction Action - if error goto E Commit goto End E: Rollback End

7. The Relational Model7 Operation of a Transaction The system must remember the changes a log or before and after Commit seals the changes makes them permanent Implicit or explicit call to Rollback by the user application by the system if it crashes

8. The Relational Model8 Transactions in SQL By default each statement is a transaction Typically - Access queries, psql etc. There will be a command to turn on multi- statement transactions START TRANSACTION But some statements are defined to be transaction initiating -all the sensible ones COMMIT ROLLBACK

9. The Relational Model9 General Example UPDATE …; INSERT INTO …; UPDATE …; COMMIT;

10. The Relational Model10 Transactions are the unit of: 1.Integrity the database is in a consistent state after a transaction Logically – the set has been done Practically – deferred constraints applied 2.Concurrency 3.Recovery

11. The Relational Model11 Transactions as units of concurrency

12. The Relational Model12 Concurrency in DB Most databases are multi-user Single user systems often allow 1 user to do >1 thing at once much the same effect A single multi-threaded application program again, the same effect Must ensure that one user’s work does not interfere with others

13. The Relational Model13 Problems with Concurrency Making things run “concurrently” not hard Causes no problems in itself Interaction of concurrent activities causes problems they are not much use if they don’t Interaction by communication not much problem in DBs Interaction by shared use of “resources” our problem – resources are data

14. The Relational Model14 Not limited to databases Operating Systems Where many of the ideas were worked out Resources may be memory, peripherals etc. Real-time control Where things must be done concurrently and in time Telecommunications Media synchronisation

15. The Relational Model15 What sort of interaction? Sometimes we want it Typically not in DBs All sorts Application dependent What the code is Time dependent “Race conditions” It depends what happens first It is useful to think of some “classic” problem situations (These are not how DBMS run – it’s how they could if not properly built and used)

16. The Relational Model16 Example DB Problem 1 Lost update - Retrieve v - Update v - Retrieve v - Update v -

17. The Relational Model17 Example DB Problem 2 Uncommitted Data - Retrieve v - Update v - Rollback - Different if LH job updates

18. The Relational Model18 Example DB Problem 3 Inconsistent Analysis One job is totalling accounts Another is moving money from one to another The first might miss the money add destination account before it reaches there add source account after it leaves there

19. The Relational Model19 Serialisability The conceptual solution Serial execution of transactions means one after another No fixed order – just chance arrival times This must avoid interference No concurrency of execution Does not dictate a unique final DB state Sequence of execution is significant Non-serial execution means interleaving

20. The Relational Model20 Serialisability means … Finding a non-serial schedule which leaves the DB in a state which one the the possible serial schedules would have In practice, interleaving execution so that there is: An efficieny gain No interference

21. The Relational Model21 We also need “Recoverability” Some serialisable schedules would preclude rollback Durability means we cannot undo a committed transaction Atomicity means we may want to rollback some other transaction But after some schedules, rollback is impossible without undoing a committed transaction

22. The Relational Model22 Ensuring Serialisability

23. The Relational Model23 General Approaches 1.Delay everything which could be a problem Slows the system Is safe Locking – most common 2.Let things proceed assuming that few problems will arise Detect an clean up the rare conflicts

24. The Relational Model24 Locking Gain sole control of a section of data use it release the lock Read and Write locks shared and exclusive >1 simultaneous read lock only 1 simultaneous write lock Locks may be refused

25. The Relational Model25 What is “a section of data” The DB? A Table? A Record? A Field in a record? (A Page – set of records) The finer the granularity the more concurrency you could have … but the work an application prog must do and the more locking info a DBMS must store

26. The Relational Model26 2-phase locking To ensure serialisability transactions must do more 2PL is the commonest protocol Growing phase Transaction acquire locks (or upgrades shared to exclusive locks) Shrinking phase Transaction releases locks (or downgrades exclusive to shared locks)

27. The Relational Model27 Locking - Good or bad? Good transaction knows the data will not change only one process can alter the data … they work Bad Deadlock Real Bad!

28. The Relational Model28 Deadlock I want that I am keeping that I am keeping that

29. The Relational Model29 Deadlock Treatment Much literature Detection and rollback is one technique detect a deadlock (inspection or timeout) pick a transaction to kill rollback and restart Others strategies for acquiring resources

30. The Relational Model30 Transactions as units of Recovery

31. The Relational Model31 Failure Failure leaves the DB in an inconsistent state at least suspect Could be failure due to integrity checks deadlock hardware failure system crash power cut...

32. The Relational Model32 Handling Failure The fundamental solution is redundancy make sure we have enough redundant data so that we can reconstruct lost or suspect data hidden from the user Logs are kept updates commit With saved system states

33. The Relational Model33 Rollback If called instead of COMMIT Work back through the log for this transaction undo each update “before” values are saved

34. The Relational Model34 System Recovery You have a consistent state saved save checkpoint where log and DB agree You know what was happening which transactions were committed which transactions were not You can undo and redo updates