22-09-2207noea/it - fen: databases/transactions1 transactions acid concurrency control

22-09-2207 NOEA/IT - FEN: Databases/Transactions

1

Transactions

ACID Concurrency Control

22-09-2207 NOEA/IT - FEN: Databases/Transactions

2

Transaction - Definition

• A transaction is an operation on data in the database.• A transaction may be composed of several database operations,

but is viewed as a logical unit of work• A transaction must be done completely or not done at all• A transaction must have the ACID properties:

– A: Either it is done in total or it is not done at all (Atomicity)– C: The database moves from one consistent state to an other

consistent state (Consistency)– I: If more operations are accessing the same that, they are not to

disturb each other – the must execute as if they executed alone (Isolation)

– D: When a transaction completes, its changes to the database are permanent (Durability)

22-09-2207 NOEA/IT - FEN: Databases/Transactions

3

Transactions – example:T1 and T2 are executing concurrently

• T1: Transfers N DKKs from account X to account Y:read_item(X);X:= X-N;write_item(X);read_item(Y);Y:= Y+N;write_item(Y);

• T2: Deposits M DKK on account Y:

read_item(Y);Y:= Y+M;write_item(Y);

timeAny possible problems?

22-09-2207 NOEA/IT - FEN: Databases/Transactions

4

Transactions - Problems

• We want several transactions to execute concurrently (Why?)

• Three types of problems:– lost update– uncommitted dependency (temporary update)– inconsistent analysis (incorrect summary)

• Crash during execution of a transaction must be handled

22-09-2207 NOEA/IT - FEN: Databases/Transactions

5

Lost Update

• Fig. 19.3a

22-09-2207 NOEA/IT - FEN: Databases/Transactions

6

Uncommitted Dependency

• Fig. 19.3b

22-09-2207 NOEA/IT - FEN: Databases/Transactions

7

Inconsistent Analysis

• Fig 19.3c

22-09-2207 NOEA/IT - FEN: Databases/Transactions

8

Transaction States• Operations:

– Begin_transaction– read and write– end_transaction:

• A transaction is in a committed state when it completes normally and changes can be written to the database

• May also complete in abort (or rollback) state. In that case any changes to the database made by that transaction are to be undone (or rolled back)

22-09-2207 NOEA/IT - FEN: Databases/Transactions

9

Transaction States

22-09-2207 NOEA/IT - FEN: Databases/Transactions

10

The Log File

• Holds information about:– start_transaction– write_item()– read_item()– commit– abort

UPDATE/INSERT/DELETE

in SQL

SELECTin SQL

ROLLBACK in some DBMSs

22-09-2207 NOEA/IT - FEN: Databases/Transactions

11

Concurrency Control

• Aim: to ensure consistency allowing maximum concurrency:– If all transactions are executed in sequence (serial), then

consistency is assured, but no concurrency is allowed– If a parallel execution of a number of transactions is

equivalent to a serial execution of the same transactions, then the executions schema is serialisable

22-09-2207 NOEA/IT - FEN: Databases/Transactions

12

Concurrency Control and Recovery

• Concurrency control: Managing concurrent execution of transactions, so no operations are conflicting

• Recovery: Re-establishing the database in a consistent state after some error

• The two are connected: concurrency control based on rollback is using the ability to recover

• Recovery and rollback (abort) are based on logging

22-09-2207 NOEA/IT - FEN: Databases/Transactions

13

Concurrency Control Techniques

• locking:– Two Phase Locking (= = 2PL)

• time stamps• multi version techniques• optimistic methods

22-09-2207 NOEA/IT - FEN: Databases/Transactions

14

Concurrency Control - Locking• A transaction can get a lock on an object in the

database so no other transaction can access that object.

• An object may be– Read-locked (shared-locked): Some transaction(s) is (are)

reading the object– Write-locked (Exclusive-locked): Some transaction is writing

to the object– Unlocked

• Deadlock is possible• The granularity of the locking system? (table, row,

row set, attributes,…?)

22-09-2207 NOEA/IT - FEN: Databases/Transactions

15

Deadlock Prevention

• Conservative 2PL-protocol:– all affected objects are locked at transactions start– are the needed locks not available the locks already

acquired are released and the transaction is restarted later– If all locks are acquired they are hold until the transaction

completes• Guarantees deadlock-free executions• Provides very little concurrency• Is unrealistic in practical use• More about alternative (and not deadlock-free)

versions of the 2PL protocol

22-09-2207 NOEA/IT - FEN: Databases/Transactions

16

Deadlock Detection: wait-for-graph

Maybe simply time-out

22-09-2207 NOEA/IT - FEN: Databases/Transactions

17

Exercise

22-09-2207 NOEA/IT - FEN: Databases/Transactions

18

Concurrency Control - 2PL• If transactions get locks on objects before accessing

confliction operations can be avoided• Two-phase locking (2PL) protocol:

– No lock is to be taken after first unlock– Expanding Phase: We are gathering objects (and may start to

use them). If an object is already locked we will wait and try again later.

– Shrinking Phase: We releasing objects again.

– Strict 2PL hold locks until commit.– By releasing objects as we are finished with them, we allow

for more concurrency, but increases the risk of cascading abort (rollback).

22-09-2207 NOEA/IT - FEN: Databases/Transactions

19

2PL

time

#objects locked

Growing phase

Shrinking phase

22-09-2207 NOEA/IT - FEN: Databases/Transactions

20

2PL

• 2PL guarantees serialisable execution at the cost of concurrency

• Deadlocks may occur.Usually handled by aborting (and restarting) transactions that repeatedly time out waiting for a lock on some object.

• The ability to recover is normally present already in the recovery system.

• Conservative 2PL guarantees deadlock prevention

22-09-2207 NOEA/IT - FEN: Databases/Transactions

21

Concurrency Control - Timestamps• At transaction start every transaction is assigned a time stamp

representing the starting time.• Every time a transaction is accessing an object, the time stamp

of the transactions is stored (with the object).

• Transactions are only allowed to access objects in time stamp order:– If T1 accesses object A and T2 then tries to access object A, then it

is:• OK If(T1.TimeStamp is earlier than T2.TimeStamp) • ERROR : If(T2.TimeStamp is earlier than T1.TimeStamp) In

this case T2 is aborted and restarted later.• Serialisable execution is guaranteed.

22-09-2207 NOEA/IT - FEN: Databases/Transactions

22

Optimistic Concurrency Control (OCC)

• Assumes that conflicts are rare, because most transactions operate on different objects.

• Handle conflicts only if they actually occur.• Allow transactions to get on with their jobs.• Nothing is written physical before commit. Work is

done on a local copy of the objects involved.• At commit it is checked that execution was

serialisable – in case of conflict all involved transactions are aborted.

22-09-2207 NOEA/IT - FEN: Databases/Transactions

23

Discussion

• 2PL is most common, but has an considerable overhead due to deadlock management, especially in case of conflicts

• time stamps: concurrency control is done on the affected object, and hence is a very nice strategy in distributed systems and in the case of few conflicts

• optimistic methods: efficient if there are few conflicts, also preferable if there are real time requirements– optimistic locking is widely used in web-systems

Why?

22-09-2207 NOEA/IT - FEN: Databases/Transactions

24

SQL Support for Transactions

• By default any SQL statement is considered to be atomic, that is: a transaction.

• Transactions involving more than one SQL statement must be opened by BeginTransaction() and terminated by either Commit() or Rollback().

• It is possible to specify the isolation level of a transaction:– ReadUncommitted– ReadCommitted (Default on MS SQL Server)– RepeatableRead – Serializable

22-09-2207 NOEA/IT - FEN: Databases/Transactions

25

MS SQL Server: Isolation Levels

22-09-2207 NOEA/IT - FEN: Databases/Transactions

26

Recovery - Why• To be able to re-establish the system into a

consistent state after some crash• To be able to use abort (rollback):

– in concurrency control– From the transaction itself

22-09-2207 NOEA/IT - FEN: Databases/Transactions

27

Recovery - How

• Recovery is usually based on– logging (remember what you are doing)

• But may also be based on– shadowing (updates are done on a copy and

written to the database later)

22-09-2207 NOEA/IT - FEN: Databases/Transactions

28

Recovery - logging

• Execute all updates, but remember in the log-file what is executed

• From the log one can do– redo: execute again– undo: write back before values (rollback)

• The log holds information about:– which transaction executes

• which operations on• which objects with• which arguments (values)

– State before and after the operation– Begin_transaction, commit and abort (rollback)

22-09-2207 NOEA/IT - FEN: Databases/Transactions

29

Recovery…

• The log must be force-written to disc before a transaction commits

• A checkpoint is entered into the log. At checkpoint:– All database objects and the log are force-written– The checkpoint is recorded

• To do recovery– Start with a consistent version of the database (that is at a

checkpoint)– From the log a Undo-list and a Redo-list is created– The Undo-list is traversed firstly, then the Redo-list– If deferred update is used, then Undo is not necessary

22-09-2207 NOEA/IT - FEN: Databases/Transactions

30

Recovery… Undo?Redo?