data concurrency, consistency and integrity

Giovanni Chierico | May 2012 | Дубна

Data Concurrency, Consistency and Integrity

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

Giovanni Chierico | May 2012 | Дубна

You

• Programming• Databases• Concurrency• SQL• Oracle

3

Giovanni Chierico | May 2012 | Дубна

A Simple Model

Processor

Memory

Read Write

1.Read2.Process3.Write4.Read5.Process6.Write7.…

4

Giovanni Chierico | May 2012 | Дубна

Increase a counter: Single User

1

1+1 2⇒

Time2 2

2+1 3⇒

3

5

Giovanni Chierico | May 2012 | Дубна

Increase a counter: Multi User

1

1+1 2⇒

Time1 2 2

1+1 2⇒

6

Giovanni Chierico | May 2012 | Дубна

Increase a counter: Multi User

1

1+1 2⇒

Time1 2

1+1 2⇒

2 3 2

2+1 3⇒

7

Giovanni Chierico | May 2012 | Дубна

Locking

1

1+1 2⇒

Time1 2 2

1+1 2⇒

ReadLock

WriteLock

8

Giovanni Chierico | May 2012 | Дубна

Concurrency

Data Concurrency means that many users can access data at the same time

Locks limit concurrency

9

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:200€T:150€

10

Giovanni Chierico | May 2012 | Дубна

Transaction

A transaction comprises a unit of work treated in a coherent and reliable way independent of other transactions.

11

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

Giovanni Chierico | May 2012 | Дубна

Transaction Properties

•Atomicity (all or nothing)

•Consistency (From Valid to Valid)

•Isolation (No interference)

•Durability (Changes are reliably persisted)

ACID13

Giovanni Chierico | May 2012 | Дубна

Commit

1

1+1 2⇒

2

1 1 2

Transaction#1

Transaction#2

Commit

Multiple versions must be kept14

Giovanni Chierico | May 2012 | Дубна

Transfer Funds: Commit

A:100€B:100€

Transfer 50€

A:50€B:100€

A:50€B:150€

T:200€ T:200€ T:200€

Commit

T#1

T#2

15

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

Giovanni Chierico | May 2012 | Дубна

Transaction Isolation LevelsRead Phenomena

• Dirty Reads: read uncommitted data of another transaction

• Nonrepeatable & Phantom Reads: read changes committed by another transaction

Oracle Isolation Lvl Dirty Reads Nonrep & Phantom

Read Committed NO YES

Serializable NO NO

17

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

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

Giovanni Chierico | May 2012 | Дубна

Multiversion Concurrency ControlSystem Change Number (SCN): the Oracle database “clock”, incremented at every insert, update, delete.

A 1 2 14

B 1 10 11 18 19

C 1 3 5

D 1 4 9 17

E 1 8 12

F 1 6 13 16

G 1 7 15

A query made at (SCN) time T return the most recent (highest SCN) records whose SCN is less or equal to T

Read SCN = 1Read SCN = 10

Readers never block WritersWriters never block Readers

*except when they do

*

20

Giovanni Chierico | May 2012 | Дубна

Updates: LocksWrite 1

1

T#1

T#2

Commit

Write 2

2

CommitWait

21

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

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

Giovanni Chierico | May 2012 | Дубна

Increase a Counter

1.Lock2.Read 3.Compute4.Update5.Commit

1.Lock

2.Read 3.Compute4.Update5. Commit

Wait

1

1

22

2

33

24

Giovanni Chierico | May 2012 | Дубна

Optimistic Locking1. 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. Lock4. Check version ⇒ Exception

B|2

B

A|1A|1

C

25

Giovanni Chierico | May 2012 | Дубна

Deadlocks

Transaction #2

Update B

Update A

Transaction #1

Update A

Update BWait #2Wait #1

Deadlock!

Avoid by always locking in the same order.

26

Giovanni Chierico | May 2012 | Дубна

Data IntegrityEnforce Business Rules

Player• have a last name• have age > 0• have a unique login name• belong to a team (reference)

27

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. Check3. Insert4. Commit

DBs offer a proper “unique” constraint.

28

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

Giovanni Chierico | May 2012 | Дубна

Q&A

30

Giovanni Chierico | May 2012 | Дубна

спасибо

Globe of Science and Innovation, CERN

31

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

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

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

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