1. Giovanni Chierico | May 2012 | Дубна Data Concurrency, Consistency and Integrity

2. Giovanni Chierico | May 2012 | Дубна My goals Managing Data Keep it valid Let people access it Start from simple models Build more complex ones High-Level Abstraction Oracle implementation No Code 2

3. Giovanni Chierico | May 2012 | Дубна You Programming Databases Concurrency SQL Oracle 3

4. Giovanni Chierico | May 2012 | Дубна A Simple Model Processor Memory ReadWrite 1.Read 2.Process 3.Write 4.Read 5.Process 6.Write 7.… 4

5. Giovanni Chierico | May 2012 | Дубна Increase a counter: Single User 1 1+1 ⇒ 2 Time 22 2+1 ⇒ 3 3 5

6. Giovanni Chierico | May 2012 | Дубна Increase a counter: Multi User 1 1+1 ⇒ 2 Time 122 1+1 ⇒ 2 6

7. Giovanni Chierico | May 2012 | Дубна Increase a counter: Multi User 1 1+1 ⇒ 2 Time 12 1+1 ⇒ 2 232 2+1 ⇒ 3 7

8. Giovanni Chierico | May 2012 | Дубна Locking 1 1+1 ⇒ 2 Time 122 1+1 ⇒ 2 Read Lock Write Lock 8

9. Giovanni Chierico | May 2012 | Дубна Concurrency Data Concurrency means that many users can access data at the same time Locks limit concurrency 9

10. Giovanni Chierico | May 2012 | Дубна Transfer Funds: Consistency A:100€ B:100€ Transfer 50€: (100,100) ⇒ (50,150) A:50€ B:100€ A:50€ B:150€ T:200€ T:150€ 10

11. Giovanni Chierico | May 2012 | Дубна Transaction A transaction comprises a unit of work treated in a coherent and reliable way independent of other transactions. 11

12. Giovanni Chierico | May 2012 | Дубна Transfer Funds: Failures A:100€ B:100€ Transfer 50€: (100,100) ⇒ (50,150) A:50€ B:100€ Anything can go wrong at any time 12

13. Giovanni Chierico | May 2012 | Дубна Transaction Properties Atomicity (all or nothing) Consistency (From Valid to Valid) Isolation (No interference) Durability (Changes are reliably persisted) ACID 13

14. Giovanni Chierico | May 2012 | Дубна Commit 1 1+1 ⇒ 2 2 112 Transaction #1 Transaction #2 Commit Multiple versions must be kept 14

15. Giovanni Chierico | May 2012 | Дубна Transfer Funds: Commit A:100€ B:100€ Transfer 50€ A:50€ B:100€ A:50€ B:150€ T:200€ Commit T#1 T#2 15

16. Giovanni Chierico | May 2012 | Дубна Transfer Funds: Rollback A:100€ B:100€ Transfer 50€ A:50€ B:100€ A:100€ B:100€ Rollback Automatic or user initiated 16

17. Giovanni Chierico | May 2012 | Дубна Transaction Isolation Levels Read Phenomena Dirty Reads: read uncommitted data of another transaction Nonrepeatable & Phantom Reads: read changes committed by another transaction Oracle Isolation LvlDirty ReadsNonrep & Phantom Read CommittedNOYES SerializableNO 17

18. Giovanni Chierico | May 2012 | Дубна Oracle Read Consistency Statement-Level Read Consistency is always guaranteed Session-Level Read Consistency is guaranteed in only serializable mode 18

19. Giovanni Chierico | May 2012 | Дубна Oracle Read Consistency A:50€ B:150€ Transfer 50€ T#1 T#2 A:100€B:100 or 150€? Same read ⇒ 100€ Multiple reads Read committed ⇒ 150€ Serializable ⇒ 100€ Same read? A:100€ B:100€ 19

20. Giovanni Chierico | May 2012 | Дубна Multiversion Concurrency Control System Change Number (SCN): the Oracle database “clock”, incremented at every insert, update, delete. A1214 B110111819 C135 D14917 E1812 F161316 G1715 A query made at (SCN) time T return the most recent (highest SCN) records whose SCN is less or equal to T Read SCN = 1 Read SCN = 10 Readers never block Writers Writers never block Readers Readers never block Writers Writers never block Readers *except when they do * 20

21. Giovanni Chierico | May 2012 | Дубна Updates: Locks Write 1 1 T#1 T#2 Commit Write 2 2 Commit Wait 21

22. Giovanni Chierico | May 2012 | Дубна Locks: Implicit Vs Explicit Implicit Locks Automatic for every operation Locks as little as possible for highest concurrency Explicit Locking transaction-level read consistency (repeatable reads) Cannot afford to wait once it has started 22

23. Giovanni Chierico | May 2012 | Дубна Increase a Counter 1.Read 2.Compute 3.Update 4.Commit 1.Read 2.Compute 3.Update 4.Commit Wait 1 1 2 2 1 2 2 23

24. Giovanni Chierico | May 2012 | Дубна Increase a Counter 1.Lock 2.Read 3.Compute 4.Update 5.Commit 1.Lock 2.Read 3.Compute 4.Update 5. Commit Wait 1 1 2 2 2 3 3 24

25. Giovanni Chierico | May 2012 | Дубна Optimistic Locking 1.Read Value & Version 2.Compute 3.Lock 4.Check if version changed. If no (1=1) then 5.Update Value & Version 6.Commit A|1 1.Read Value & Version 2.Compute 3.Lock 4.Check version ⇒ Exception B|2 B A|1 C 25

26. Giovanni Chierico | May 2012 | Дубна Deadlocks Transaction #2 Update B Update A Transaction #1 Update A Update B Wait #2 Wait #1 Deadlock! Avoid by always locking in the same order. 26

27. Giovanni Chierico | May 2012 | Дубна Data Integrity Enforce Business Rules Player have a last name have age > 0 have a unique login name belong to a team (reference) 27

28. Giovanni Chierico | May 2012 | Дубна Unique Constraint Insert new player with login “chierico” Check that no other “chierico” exists Insert new “chierico” record Make sure no one insert it between your “check” and your “insert” ⇒ 1.Lock whole table ⇒ Bad for Concurrency 2.Check 3.Insert 4.Commit DBs offer a proper “unique” constraint. 28

29. Giovanni Chierico | May 2012 | Дубна Lessons Learned Always think about how others might use the data No “one solution fits all” Databases offer valuable abstractions Flexible Safe Declarative Not all databases behave the same way 29

30. Giovanni Chierico | May 2012 | Дубна Q&A 30

31. Giovanni Chierico | May 2012 | Дубна спасибо Globe of Science and Innovation, CERN 31

32. Giovanni Chierico | May 2012 | Дубна 32

33. Giovanni Chierico | May 2012 | Дубна 33

34. Giovanni Chierico | May 2012 | Дубна 34

35. Giovanni Chierico | May 2012 | Дубна 35