Download transaction

Transactions
ACID
Concurrency Control
22-09-2207
NOEA/IT - FEN: Databases/Transactions
1
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
2
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?
22-09-2207
NOEA/IT - FEN: Databases/Transactions
3
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
4
Lost Update
• Fig. 19.3a
22-09-2207
NOEA/IT - FEN: Databases/Transactions
5
Uncommitted Dependency
• Fig. 19.3b
22-09-2207
NOEA/IT - FEN: Databases/Transactions
6
Inconsistent Analysis
• Fig 19.3c
22-09-2207
NOEA/IT - FEN: Databases/Transactions
7
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
8
Transaction States
22-09-2207
NOEA/IT - FEN: Databases/Transactions
9
The Log File
• Holds information about:
– start_transaction
– write_item()
– read_item()
– commit
– abort
UPDATE/INSERT/
DELETE
in SQL
SELECT
in SQL
ROLLBACK in some
DBMSs
22-09-2207
NOEA/IT - FEN: Databases/Transactions
10
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
11
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
12
Concurrency Control Techniques
• locking:
– Two Phase Locking (= = 2PL)
• time stamps
• multi version techniques
• optimistic methods
22-09-2207
NOEA/IT - FEN: Databases/Transactions
13
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
14
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
15
Deadlock Detection: wait-for-graph
Maybe simply time-out
22-09-2207
NOEA/IT - FEN: Databases/Transactions
16
Exercise
22-09-2207
NOEA/IT - FEN: Databases/Transactions
17
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
18
2PL
#objects locked
Shrinking phase
Growing phase
time
22-09-2207
NOEA/IT - FEN: Databases/Transactions
19
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
20
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
21
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
22
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
23
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
24
MS SQL Server: Isolation Levels
22-09-2207
NOEA/IT - FEN: Databases/Transactions
25
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
26
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
27
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
28
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
29
Redo?
22-09-2207
Recovery…
NOEA/IT - FEN: Databases/Transactions
Undo?
30