22-09-2207noea/it - fen: databases/transactions1 transactions acid concurrency control
DESCRIPTION
NOEA/IT - FEN: Databases/Transactions3 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); time Any possible problems?TRANSCRIPT
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?