Professional Documents
Culture Documents
3 4
5 6
State Transition Diagram for Transaction Properties of Transactions
Four basic (ACID) properties of a transaction are:
7 8
9 10
11 12
Lost Update Problem Uncommitted Dependency Problem
Occurs when one transaction can see
intermediate results of another transaction
before it has committed.
T4 updates balx to £200 but it aborts, so balx
should be back at original value of £100.
T3 has read new value of balx (£200) and uses
value as basis of £10 reduction, giving a new
Loss of T2’s update avoided by preventing T1 balance of £190, instead of £90.
from reading balx until after update.
13 14
15 16
19 20
21 22
24
Precedence Graph Example - Non-conflict serializable schedule
Create: T9 is transferring £100 from one account with
– node for each transaction; balance balx to another account with balance
– a directed edge Ti → Tj, if Tj reads the value baly.
of an item written byy Ti; T10 is increasing balance of these two accounts by
25 26
27 28
29 30
Recoverable Schedule Concurrency Control Techniques
A schedule where, for each pair of transactions Two basic concurrency control techniques:
Ti and Tj, if Tj reads a data item previously – Locking,
written by Ti, then the commit operation of Ti – Timestamping.
precedes the commit operation of Tj.
Both are conservative approaches: delay
Ti → Tj transactions in case they conflict with other
transactions.
Optimistic methods assume conflict is rare and
only check for conflicts at commit.
31 32
35 36
Example - Incorrect Locking Schedule Example - Incorrect Locking Schedule
For two transactions in previous slide, a valid If at start, balx = 100, baly = 400, result should be:
schedule using these rules is:
– balx = 220, baly = 330, if T9 executes before T10,
S = {write_lock(T9, balx), read(T9, balx), write(T9, balx), or
unlock(T9, balx),
) write_lock(T
write lock(T10, balx),) read(T10, balx),
) – bal
b lx = 210,
210 bal
b ly = 340,
340 if T10 executes before
b f T9.
write(T10, balx), unlock(T10, balx), write_lock(T10,
baly), read(T10, baly), write(T10, baly), unlock(T10, However, result gives balx = 220 and baly = 340.
baly), commit(T10), write_lock(T9, baly), read(T9,
baly), write(T9, baly), unlock(T9, baly), commit(T9) } S is not a serializable schedule.
37 38
41 42
Preventing Inconsistent Analysis Problem using
2PL Cascading Rollback
If every transaction in a schedule follows 2PL,
schedule is serializable.
However, problems can occur with
interpretation of when locks can be released.
43 44
45 46
Deadlock Deadlock
A situation in which no progress can be made or no
advancement is possible Only one way to break deadlock: abort one or
An impasse that may result when two (or more) more of the transactions.
transactions are each waiting for locks held by the other to Deadlock should be transparent to user, so
be released. DBMS should restart transaction(s).
Three general techniques for handling deadlock:
– Timeouts.
– Deadlock prevention.
– Deadlock detection and recovery.
47 48
Timeouts Deadlock Prevention
Transaction that requests lock will only wait for a DBMS looks ahead to see if transaction would
system-defined period of time. cause deadlock and never allows deadlock to
If lock has not been granted within this period, occur.
lock request times out. Could order transactions using transaction
In this case, DBMS assumes transaction may be timestamps:
deadlocked, even though it may not be, and it – Wait-Die - only an older transaction can wait
aborts and automatically restarts the transaction. for younger one, otherwise transaction is
aborted (dies) and restarted with same
timestamp.
49 50
51 52
53 54
Concurrency Control Techniques:
2-Timestamping Timestamping
Transactions ordered globally so that older Timestamp
transactions, transactions with smaller A unique identifier created by DBMS that
timestamps, get priority in the event of conflict. indicates relative starting time of a
Conflict is resolved by rolling back and transaction.
restarting transaction. Can be generated by using system clock at time
No locks so no deadlock. transaction started, or by incrementing a logical
counter every time a new transaction starts.
55 56
59 60
Example – Basic Timestamp Ordering
Modification: Thomas’s write rule
Timestamping - Transaction T issues a Write(x)
Ignored
--ignore obsolete
write rule
61 62
63 64
65 66
Optimistic Techniques - Write Phase Granularity of Data Items
Follows successful validation phase for update Size of data items chosen as unit of protection by
transactions. concurrency control protocol.
Ranging from coarse to fine:
Updates made to local copy are applied to the
– The entire database.
d t b
database.
– A file.
– A page (or area or database spaced).
– A record.
– A field value of a record.
67 68
73 74
83 84
Main Recovery Techniques Deferred Update
Three main recovery techniques: Updates are not written to the database until
after a transaction has reached its commit point.
– Deferred Update
If transaction fails before commit, it will not have
– Immediate Update modified database and so no undoing of changes
– Shadow
Sh d Paging
P i required.
May be necessary to redo updates of committed
transactions (using log file) as their effect may
not have reached database.
85 86
87 88
89 90
Advanced Transaction Models Advanced Transaction Models
May result in transactions of long duration, We will look at two advanced transaction models:
giving rise to following problems:
– More susceptible to failure - need to minimize – Nested Transaction Model
amount of work lost. – Sagas
– May
M access large
l number
b off data
d t items
it -
concurrency limited if data inaccessible for
long periods.
– Deadlock more likely.
– Cooperation through use of shared data items
restricted by traditional concurrency
protocols.
91 92
93 94
95 96
Nested Transaction Model - Advantages Emulating Nested Transactions using Savepoints
Modularity - transaction can be decomposed into An identifiable point in flat transaction
number of subtransactions for purposes of concurrency representing some partially consistent state.
and recovery.
Finer level of granularity for concurrency control and Can be used as restart point for transaction if
recovery.
subsequent problem detected.
– Occurs at the level of subtransaction rather than the
transaction During execution of transaction, user can
Intra-transaction parallelism. establish savepoint, which user can use to roll
– Subtractions can execute concurrently transaction back to.
Intra-transaction recovery control. Unlike nested transactions, savepoints do not
– Uncommitted subtransactions can be aborted and rolled support any form of intra-transaction
back without any side effects to other subtransactions parallelism.
97 98
Sagas Sagas
“A sequence of (flat) transactions that can be Relax property of isolation by allowing saga to
interleaved with other transactions”. reveal its partial results to other concurrently
executing transactions before it completes.
DBMS guarantees that either all transactions in Useful when subtransactions are relatively
saga are successfully
f ll completed
l t d or compensating
ti independent and compensating transactions can
transactions are run to undo partial execution. be produced.
Saga has only one level of nesting. May be difficult sometimes to define
For every subtransaction defined, there is
compensating transaction in advance, and DBMS
corresponding compensating transaction that may need to interact with user to determine
will semantically undo subtransaction’s effect. compensation.
99 100