Data Concurrency, Consistency and Integrity

Giovanni Chierico | May 2012 | Дубна

Data Concurrency, Consistency and Integrity


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


You

• Programming• Databases• Concurrency• SQL• Oracle

3


A Simple Model

Processor

Memory

Read Write

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

4


Increase a counter: Single User

1

1+1 2⇒

Time2 2

2+1 3⇒

3

5


Increase a counter: Multi User

1

1+1 2⇒

Time1 2 2

1+1 2⇒

6


Increase a counter: Multi User

1

1+1 2⇒

Time1 2

1+1 2⇒

2 3 2

2+1 3⇒

7


Locking

1

1+1 2⇒

Time1 2 2

1+1 2⇒

ReadLock

WriteLock

8


Concurrency

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

Locks limit concurrency

9


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


Transaction

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

11


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


Transaction Properties

•Atomicity (all or nothing)

•Consistency (From Valid to Valid)

•Isolation (No interference)

•Durability (Changes are reliably persisted)

ACID13


Commit

1

1+1 2⇒

2

1 1 2

Transaction#1

Transaction#2

Commit

Multiple versions must be kept14


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


Transfer Funds: Rollback

A:100€B:100€

Transfer 50€

A:50€B:100€

A:100€B:100€

Rollback

Automatic or user initiated

16


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


Oracle Read Consistency

Statement-Level Read Consistency is always guaranteed

Session-Level Read Consistency is guaranteed in only serializable mode

18


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


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


Updates: LocksWrite 1

1

T#1

T#2

Commit

Write 2

2

CommitWait

21


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


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


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


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


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


Data IntegrityEnforce Business Rules

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

27


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


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


Q&A

30


спасибо

Globe of Science and Innovation, CERN

31

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




Documents

Data Concurrency, Consistency and Integrity