TDDC94
Fall 2007
Lecture Overview
TDDC94—Transactions & Concurrency
User 4
Model
Real World
Updates
Answers
UserQueries
3
Updates
Answers
UserQueries
2
UserQueries
1
Updates
Answers
Updates Queries Answers
based on Chapters 17, 18
Database
Processing of
queries and updates
Database
management
system
Almut Herzog
Attentec AB
almhe@attentec.se
almhe@ida.liu.se
Access to stored data
Physical
database
September 26,
2007
TDDC94—Transactions and Concurrency
Transactions
„
„
„
„
Transactions
A transaction is a logical unit of computations in the
database.
A transactions starts with the start transaction keyword
(or implicitly) and ends with commit or rollback
It consists of one or more database statements (read or
write in the DB) that shall be treated as a unit which can
be undone/rolled back.
Desirable properties:
‰
‰
‰
‰
atomic: It is either performed in its entirety or not at all (rolled
back),
preserves consistency: from one consistent state to another
isolated: appears as if it is a single-user system
durable or permanent: Committed actions are permanent.
TDDC94—Transactions and Concurrency
2
„
Typical statements in a transaction (pseudo-code instead
of SQL):
‰
read-item(X)
„
„
„
‰
write-item(X)
„
„
„
„
‰
locate the block on disk that contains X
copy the block to primary memory (a buffer)
copy X from the buffer to local variable X
locate the block on disk where X should be written
copy the block to primary memory (a buffer)
copy X from the local variable to the right place in the buffer
store the modified block back to disk
transactions terminate with rollback/abort or commit
TDDC94—Transactions and Concurrency
3
Transactional problems—The Temporary
Update or Dirty Read
T1
4
Transactional problems—The Lost Update
T2
T1
read_item(X);
read_item(X);
X := X-N;
X := X-N;
T2
read_item(X);
write_item(X);
read_item(X); Å Dirty X
X := X+M
X := X+M
write_item(X); Å lost X
write_item(X);
write_item(X);
rollback;
Of all transactional problems, this is the most basic one that every DBMS
provides a solution for.
One should never be able to see uncommited data of other transactions.
TDDC94—Transactions and Concurrency
Author: Almut Herzog
5
TDDC94—Transactions and Concurrency
6
1
TDDC94
Fall 2007
Transactional problems—The Incorrect
Summary Problem
T1
Transactional problems—Unrepeatable
Read
T2
T1
sum := 0;
T2
read_item(X);
read_item(X);
read_item(X);
X := X-N;
X := X-N;
write_item(X);
write_item(X);
read_item(X);
read_item(X); Å Different X
than at the first read_item
sum := sum + X; Å lost N
read_item(Y);
sum := sum + Y;
Not all DBMSs provide a default solution because the solution is costly.
read_item(Y);
Y := Y+N;;
write_item(Y);
TDDC94—Transactions and Concurrency
TDDC94—Transactions and Concurrency
7
Schedules
„
„
Schedule—More definitions
Schedule—order of
execution of operations
(read-item r, write-item w,
commit c, rollback a)
from the various
transactions when
transactions are
executing concurrently in
an interleaved fashion.
S: r1(X); r2(X);w1(X);w2(X)
TDDC94—Transactions and Concurrency
T1
T2
„
„
„
Author: Almut Herzog
Two operations in a schedule conflict if all three
conditions below are satisfied:
1.
2.
X := X-N;
3.
read_item(X);
‰
X := X+M
‰
write_item(X);
9
11
they belong to different transactions,
they access the same item X,
at least one of the operations is a write_item(X).
In S: r1(X); r2(X);w1(X);w2(X);
following operations conflict:
‰
write_item(X);
A schedule is a recoverable schedule if it ensures that
once a transaction T is committed, it should never be
necessary to roll it back.
A schedule S is recoverable if no transaction T in S
commits until all transactions T’ that have written an item
that T reads have committed.
It is possible for a phenomenon known as cascading
rollback to occur, where an uncommitted transaction has
to be rolled back because it read an item from a
transaction that failed. This is illustrated in schedule
S: r1(X); w1(X);r2(X); r1(Y);w2(X); w1(Y);a1; a2; where T2
has to be rolled back because it read item X from T1 and
T1 then aborted.
…
TDDC94—Transactions and Concurrency
„
read_item(X);
Schedule—More definitions
„
8
r2(X);w1(X)
r1(X); w2(X)
r2(Y);w2(Y); e.g. the
w1(X);w2(X)
e.g. these do not:
‰
r1(X); r2(X)
w1(X);w2(Y)
TDDC94—Transactions and Concurrency
10
Serializability
„
„
„
In a serial schedule only one transaction at a time is
active. There is no interleaving.
A schedule is serializable if it is equivalent to some serial
schedule of the same transactions.
Equivalence
‰
‰
„
result equivalent: schedules produce the same final state of
the database
conflict equivalent: the order of any two conflicting
operations is the same in both schedules
A schedule S is conflict-serializable if it is conflict
equivalent to some serial schedule S’
TDDC94—Transactions and Concurrency
12
2
TDDC94
Fall 2007
Testing Conflict Serializability of a
Schedule S
„
„
„
„
„
For each transaction Ti participating in schedule S, create
a node labeled Ti in the precedence graph.
For each case in S where Tj executes a read_item(X)
after Ti executes a write_item(X), create an edge (TiÆTj)
in the graph.
For each case in S where Tj executes a write_item(X)
after Ti executes a read_item(X), create an edge (TiÆTj)
in the graph.
For each case in S where Tj executes a write_item(X)
after Ti executes a write_item(X), create an edge (TiÆTj)
in the graph.
S is serializable iff the graph has no cycles.
TDDC94—Transactions and Concurrency
13
Guaranteeing Serializability by Two-Phase
Locking
„
„
„
„
„
NB: Two-phase locking is unrelated to the two-phase
commit in distributed databases!
two-phase locking protocol: all locking operations
(read_lock, write_lock) precede the first unlock operation
in the transaction.
first phase: the expanding or growing phase where new
locks are acquired
second phase: shrinking phase during which existing
locks can be released but no new locks can be acquired.
leads to little interleaving but guarantees serializability
Concurrency Control Techniques
„
„
„
„
In common DBMSs transactions come and go ad-hoc
and cannot be subjected to theoretical interleaving has
presented earlier.
Therefore protocols exist to avoid concurrency problems.
We introduce the new pseudo-commands
(un)lock_item(X)* for a binary lock that grants exclusive
read and write access to the calling transaction. This is
very coarse. *granularity level
Shared/exclusive or read/write locks provide
read_lock(X), write_lock(X) and unlock(X). A read-locked
item is also called share-locked because other
transactions are allowed to read the item, whereas a
write-locked item is called exclusive-locked because a
single transaction exclusively holds the lock on the item.
TDDC94—Transactions and Concurrency
Dealing with Deadlocks and Starvation
„
„
Deadlocks occur when each transaction in a set of two or more
transactions wait for an item that is locked by another
transaction.
prevention by
‰
‰
‰
‰
‰
locking all needed items early or failing and retrying
locking in a pre-defined global order
no-waiting algorithm: if the lock cannot be acquired, the transaction
aborts and restarts after a time delay.
cautious waiting algorithm: if the lock cannot be acquired because it
is hold by a transaction that waits for another lock, the transaction
aborts.
based on transaction timestamps TS
„
„
‰
TDDC94—Transactions and Concurrency
15
Dealing with Deadlocks and Starvation
„
Deadlocks prevented by
‰
‰
„
‰
„
‰
„
„
victim selection (for rollback) should favour short-running
transactions
timeout. Simple method, applied regardless of whether it
was a deadlock or not
based on timestamp ordering
16
Locks for concurrency control in indexes
„
wait-for graph contains a cycle
wait-die: if Ti older than Tj, Ti is allowed to wait. If Ti is younger, Ti dies
and restarts with the same timestamp,
wound-wait: If Ti is older than Tj, Tj aborts and restarts with the same
timestamp. If Ti is younger, it is allowed to wait.
TDDC94—Transactions and Concurrency
multi-version concurrency control
optimistic concurrency control
Deadlock detection by
14
Index search always starts from the root and simple
locking would lock the whole index until the shrinking
phase of the two-phase locking
Solution
‰
‰
when reading the roots can be released when the next lower
level is traversed
insert into an index where the leaf node is not full does not
require higher levels to be locked
Starvation is prevented by a fair waiting scheme such as
FIFO, priority queuing (prio increases with wait time), fair
victim selection
TDDC94—Transactions and Concurrency
Author: Almut Herzog
17
TDDC94—Transactions and Concurrency
18
3