Database Systems: Transaction Management
Post on 03-Jan-2016
55 Views
Preview:
DESCRIPTION
Transcript
1
Database Systems: Transaction Management
2
Necessity
• Database systems are normally being accessed by many users or processes at the same time.– Both queries and modifications.
• Unlike Operating Systems, which support interaction of processes, a DMBS needs to keep processes away from troublesome interactions.
3
Example: Bad Interaction• You and your father ( Joint A/c) each
take Rs. 10,000 from different ATM’s at about the same time.– The DBMS should make sure one account
deduction doesn’t get lost.
Comparison: An OS allows two people to edit a document at the same time. If both write, one’s changes get lost.
What if the connection to the bank is lost during the transaction?
Transaction Management Support
Two main issues to deal with:Concurrent execution of multiple
transactionsFailures of various kinds, such as
hardware failures and system crashes
4
Transactions: Basic concepts
TransactionA logical unit of database processing.An action or series of actions, carried out by
user or application, which accesses or changes contents of database.
Transforms database from one consistent state to another, although consistency may be violated during transaction.
Transaction Processing SystemSystems with large databases and multiple
concurrent users that are executing database transactions.
ExamplesBanking systems, Airline reservations,
Supermarket checkouts, ...
5
Database Access OperationsPerformed on a data item
read-item (X)write-item (X)
A transaction can have multiple database access operations.
Each transaction has clearly specified beginning and end statements.
A single application program may contain many transactions.
6
read-item (X), write-item (X)
Read_item(X) includes steps:1. Find the address of the disk block that contains
the item X2. Copy the disk block into a buffer in main
memory 3. Copy the item X from the buffer to a program
variable ( for simplicity also called X)
Write_item(X) includes steps:1. Find the address of the disk block that contains the item
X
2. Copy the disk block into a buffer in main memory
3. Copy the item X from a program variable into its correct location in the buffer
4. Store the updated block from the buffer back to disk
7
A Simple Transaction T1
T1:read-item (X);
X:= X + M;write-item (X);
read and write sets of a Transaction
read-set of T1 is {X} reads database item x into a program variable x
write-set of T1 is also {X} writes program value of the variable x into the
database item x 8
Another example
T2 read_item(X); X:=X-N; write_item(X); read_item(Y);
read_item(Z); Y:=Y+Z+N; write(Y);
read_set of T2 is {X,Y,Z}, write_set of T2 is {X,Y}
9
Transaction OperationsA transaction is either completed in its entirely or
not done at all.
Hence for recovery purpose, the recovery manager keeps track of the following transaction operations.
begin-transactionread-itemwrite-itemend-transactioncommitabort (or rollback)
10
11
Active
Failed
Committed
Terminated
Partially Committed
begin-transaction commit
read-item, write-item
abortabort
end-transaction
STATE
Transition
Commit Point of a Transaction TMarks the successful completion of T and having recorded
the effect of all the transaction operations on the database in the system log.
[Commit, T] is recorded in the system log
12
[start-transaction, T1]…...[start-transaction, T2]…
[commit, T2]…[commit, T1]
Rollback Point of a Transaction T
Causes the transaction to end, but by aborting.No effects on the database.
[Rollback, T] is recorded in the system logFailures like division by 0 can also cause rollback,
even if the programmer does not request it
13
[start-transaction, T1]…...[start-transaction, T2]…
[commit, T2]…[rollback, T1]
Desirable properties: ACIDTransactions should possess ACID
properties.ACID properties should be enforced by
concurrency control and recovery methods of the DBMS
Atomicity – Either the whole process is done or none is..
Consistency Preservation – Database constraints are preserved..
Isolation – It appears to the user as if only one process executes at a time.
Durability – Effects of a committed process do not get lost if the system crashes. 14
Why Concurrency Control is needed?
15
Multiple users are concurrently executing transactions
A transaction can have several data access operations, some of which could be accessing the same data item
Transaction processing systems are large databases with multiple users executing database transactions
Contd…Simultaneous execution of transactions
over a shared database can create several data integrity and consistency problems.
Transactions could be run serially, but this limits the degree of concurrency or parallelism in system.
Although two transactions may be correct in themselves, interleaving of operations may produce an incorrect result.
16
!!! Concurrency ProblemsLost updateDirty readIncorrect summaryUnrepeatable Read
17
Lost UpdateTwo transactions have their operations interleaved in such a way that it makes the value of some data items incorrect
18
T1read-item (X);X:=X-N;
write-item (X);read-item (Y);
Y:=Y+N;write-item (Y);
T2
read-item (X);X:=X+M;
write-item (X);
Item X has an incorrect
value because its update by T1 is lost
Lost update
19
T1 T2
r[x] r[x]x:=x+1
x:=x-1w[x]
w[x]r[y]y:=y-1w[y]
T i m
e
x=5 x=5x:=6
x:=4 x=6
x=4 y=2y:=1 y=1
The update of the item x by T1 is lost
Dirty read (temporary update)A transaction updates a database item and then fails. The updated item is accessed by another transaction before it is restored back to its original value
20
T1read-item (X);X:=X-N;write-item (X);
read-item (Y);Abort;
T2
read-item (X);X:=X+M;write-item (X);
T1 fails and must restore the value of X; meanwhile T2
has read the temporary
incorrect value of X
Dirty read (temporary update)
21
T1 T2
r[x]x:=x+1w[x]
r[x] x:=x+2 w[x]
r[y]Abort T1
x=5 x:=6 x=6
x=6x:=8x=8
r[y]
The value of x written to the database is equal to: initial value of x + 3, while it should be x+2
Incorrect summaryA transaction aggregating a number of records may read values of some records before, and some after the update by another transaction
22
T1
read-item (X);X:=X-N;write-item (X);
read-item (Y);Y:=Y+N;write-item (Y);
T3sum:=0;read-item(A)sum:=sum+A;
.
.
.read-item (X);sum:=sum+X;read-item (Y);sum:=sum+Y;
T3 reads X after N is subtracted,
and reads Y before N is
added; a wrong summary is calculated
Unrepeatable readA transaction reads the value of an item twice, and the value of the item is changed by another transaction in between the reads
23
T1read-item (X);
read-item (X)X:=X-N;write-item (X);
T2
read-item (X);X:=X+M;write-item (X);
T1 reads X again, however T2 has
changed the value of X after the first
read
Unrepeatable read
24
T1 T2
r[x]x:=3*xw[x]
r[x] x:=x+2 w[x]
r[y]r[x]y:=y+x/2w[y]
x=4x:=12x=12
x=12 x:=14 x=14
y=3x=14y:=10y=10
Value of x used in T1 to compute the update of y is not the value of x expected to be used
Why Recovery is needed? Two types of storage: volatile (main memory)
and nonvolatile.Volatile storage does not survive system
crashes.Reasons for the need of recovery
• Physical problems and catastrophes• Disk failure• System failure• Transaction failure• Local error or exception condition• Concurrency control enforcement.
The system must keep sufficient information to recover from the failure.
DBMS should commit changes for successful transactions and reject changes of aborted transactions.
25
Desirable properties: ACIDTransactions should possess ACID
properties.ACID properties should be enforced by
concurrency control and recovery methods of the DBMS
Atomicity – Either the whole process is done or none is..
Consistency Preservation – Database constraints are preserved..
Isolation – It appears to the user as if only one process executes at a time.
Durability – Effects of a committed process do not get lost if the system crashes. 26
SchedulesA Schedule is the order of execution of
operations from various transactions.A formal definition of a schedule is:
A schedule S of n transactions T1, T2, …, Tn is an ordering of the operations of these transactions, given that Ti S, the order of operations of Ti in S is the same as in the original Ti.
Schedules consider read-item, write-item, commit and abort operations only and the order of operations in S to be a total order.
27
Example ScheduleSa : r1 (X); r2 (X); w1 (X); r1 (Y); w2 (X);
w1 (Y);
28
T1read-item (X);X:=X-N;
write-item (X);read-item (Y);
Y:=Y+N;write-item (Y);
T2
read-item (X);X:=X+M;
write-item (X);
Notationr read-itemw write-item c commita abort
r1 (X) T1: read-item (X) a2 T2: abort
Characterising Schedules Based on RecoverabilityFor some types of schedules it is
easy to recover but not for all.Characterise the type of schedules
for which recovery is possible and relatively simple:Recoverable and nonrecoverable
schedulesCascadeless or Avoid cascading rollback
(ACR) schedules Strict schedules
29
Recoverable SchedulesSchedules that can recover from
transaction failures such that once a transaction is committed it should never be necessary to roll back.
Non recoverable schedules should not be permitted for execution.
Formally
A schedule S is recoverable if no transaction T in S commits until all transactions T` that write an item that T reads, have committed.
30
Examples of Recoverable Schedules
Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; w1(Y); a1;
T2 reads item X fromT1 and then T2 commits before T1 commits. If T1 aborts after c2 then X that T2 read is no longer valid and T2 must be aborted after it has been committed.
- Non-recoverable Schedule
Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2;
- Recoverable Schedule31
More ExamplesConsider the following schedules for two
transaction withinterleaved execution.
S1: r1[x], r2[y], w1[x], w2[y], r2[x], w2[x], c2, r1[y], a1
S2: r1[x], r2[y], r1[y], w2[y], w1[x], r2[x], w2[x], c1, c2
S1 is not recoverable since T2 reads item x written by the transaction T1 that failed.
S2 is recoverable; i.e. T2 reads items written by T1 and does not commit before T1.
In a recoverable schedule, no committed transaction ever needs to be rolled back. 32
Cascading Rollback
An uncommitted transaction has to be rolled back because it reads an item from a transaction which failed.
It can be time consuming!
33T1
T5T8
T3
T2
T6
T7
T9 T4
Suppose that T5 has to be aborted.
All transactions ‘reachable’ from T5 are aborted.
Cascadeless or ACR SchedulesCascadeless schedules are recoverable
schedules that avoid cascading rollbacks.A cascadeless schedule is guaranteed not to
be rolled back.
Formally
A schedule S is cascadeless if every transaction reads only items that were written by committed transactions.
34
Examples of Cascadeless SchedulesRecoverable Schedule with cascading
rollback
Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2;
T2 has to be rolled back because it reads X from T1 and T1 then aborted,
Cascadeless Schedule ( delaying T2)
Sf: r1(X); w1(X); a1; r2(X); w2(X); c2;
35
Strict SchedulesStrict schedules are recoverable and
cascadeless schedules that guarantee correct results.
Strict schedules simplify the recovery process.
Formally
A schedule S is strict if transactions can neither read nor write an item X until the last transaction that wrote X has committed (or aborted).
36
Examples of Strict SchedulesRecoverable and Cascadeless Schedule
with potential incorrect results.
Sg: r1(X); w1(X); w2(X); a1;
- not a strict schedule because T2 writes X before T1 commits or aborts that last wrote X.
Strict Schedule
Sh: r1(X); w1(X); a1; w2(X);
37
38
RecoverabilityAvoidance of
cascading rollback
Strictness
Characterising Schedules Based on SerializabilityCharacterise the type of schedules
that are considered correct when concurrent transactions are executing.Serial schedulesNonserial schedulesConflict-Serializable schedules
39
Serial SchedulesSchedules that execute each transaction one
by one without any interleaving.Formally
A schedule S is serial if for every transaction T participating in S, all operations of T are executed consecutively; otherwise the schedule is called nonserial.
There are n! serial schedules for n transactions
A serial schedule is always correct, but unacceptable in practice !
40
Examples of Serial SchedulesSerial Schedules (a)
41
T1read-item (X);X:=X-N;write-item (X);read-item (Y);Y:=Y+N;write-item (Y);
T2
read-item (X);X:=X+M;write-item (X);
T1
read-item (X);X:=X-N;write-item (X);read-item (Y);Y:=Y+N;write-item (Y);
T2read-item (X);X:=X+M;write-item (X);
Serial Schedules (b)
Examples of Nonserial Schedules
Non-serial Schedules (d)
42
T1read-item (X);X:=X-N;write-item (X);
read-item (Y);Y:=Y+N;write-item (Y);
T2
read-item (X);X:=X+M;write-item (X);
T1read-item (X);X:=X-N;
write-item (X);read-item (Y);
Y:=Y+N;write-item (Y);
T2
read-item (X);X:=X+M;
write-item (X);
Non-serial Schedules (c)
Results of Example Schedules
Initial Values of database itemsX = 90, Y =90, N = 3, M = 2
Results: Schedule (a): Y = 93, X =89 Schedule (b): Y = 93, X =89 Schedule (c): Y = 93, X =92 Schedule (d): Y = 93, X =89
43
We are interested in schedule like the schedule (d).
Serializable Schedules
A serializable schedule is a nonserial schedules that is equivalent to some serial schedule. it gives the correct result in spite of
interleaving.
Formally
A schedule S of n transactions is serializable if it is equivalent to some serial schedule of the same n transactions
When are two schedules ‘equivalent’?44
Schedule equivalence
Conflict EquivalenceThe order of any two conflicting operations is the
same in both schedules.View Equivalence
Each read operation of a transaction reads the result of the same write operation in both schedules.
Result EquivalenceThe two schedules produce the same final state of
the database.Other types of Equivalence
45
Conflict Equivalence and Conflicting OperationsSchedules are called conflict equivalent if the order of any two conflicting operations is same in both schedules.
Operations of a schedule are in Conflict if they satisfy all of the following conditions:• they belong to different transactions;• they access the same item X; and• at least one is a write-item (X).
An example Sa : r1 (X); r2 (X); w1 (X); r1 (Y); w2 (X); w1 (Y);
the Conflicting operations are: {r1(X) and w2(X)}, {r2(X) and w1(X)}, {w2(X) and
w1(X)} but {r1(X) and r2(X)}, {w1(X) and w2(Y)} are not in
conflict.46
Example of Conflict EquivalenceConsider two schedules:
S1: …. r1(X); w2(X); ….;S2: …. w2(X); r1(X); ….;
S1 and S2 are not conflict equivalent. r1(X) and w2(X) are conflicting operations of transactions
T1 and T2. Value read by r1(X) can be different in the two schedules.
47
Conflict SerializableA schedule S is conflict serializable if it is conflict equivalent to some serial schedule S`.
48
T1read-item (X);X:=X-N;write-item (X);read-item (Y);Y:=Y+N;write-item (Y);
T2
read-item (X);X:=X+M;write-item (X);
Serial ScheduleS`: … w1(X);…; r1(X);…;
T1read-item (X);X:=X-N;write-item (X);
read-item (Y);Y:=Y+N;write-item (Y);
T2
read-item (X);X:=X+M;write-item (X);
Conflict Serializable ScheduleS: … w1(X); r1(X);…;
Precedence GraphPrecedence Graph is used to test for
serializability
A directed graph G = (N, E), where N is a set of Nodes, N = {T1, T2, …, Tn}E is a set of directed edges, E = {e1, e2, …,
em}Each transaction Ti in the schedule has one nodeEach edge ei is (Tj Tk) 1 j n, 1 k n
The edge ei is created when an operation in Tj is followed by a conflicting operation in Tk
The schedule S is serializable iff the graph has no cyclesA path is called a cycle if it starts and ends in the
same node and contains at least two nodes.If the precedence graph contains cycle, the
schedule is not conflict serializable.49
Precedence Graph for a Serial Schedule
50
T1read-item (X);X:=X-N;write-item (X);read-item (Y);Y:=Y+N;write-item (Y);
T2
read-item (X);X:=X+M;write-item (X);
Serial ScheduleSa: … w1(X);…; r2(X);…;
T1 T2
X
Precedence Graph for Sa
Precedence Graph for a Serializable Schedule
51
T1read-item (X);X:=X-N;write-item (X);
read-item (Y);Y:=Y+N;write-item (Y);
T2
read-item (X);X:=X+M;write-item (X);
Conflict Serializable ScheduleSb: … w1(X); r2(X);…;
T1 T2
X
Precedence Graph for Sb
52
T1read-item (X);X:=X-N;
write-item (X);read-item (Y);
Y:=Y+N;write-item (Y);
T2
read-item (X);X:=X+M;
write-item (X);
Non Serializable ScheduleSc:.. r2(X);..w1(X);..w2(X);..;
Precedence Graph for Sc
T1 T2
X
X
53
r1[x], r5[z], r2[y], r2[x], r3[q], r4[s], r4[u], w2[x], w3[q], r1[t], r5[s], w4[u], w2[y], w5[z], r3[t], r1[q], r2[t], r5[x], r4[y], r3[u], r3[z], r1[p], r1[s], r3[p], w3[p], w5[x], w1[p], w1[q]
12
5
4
3
Precedence Graph: More complex example
54
r1[x], w1[x], r5[z], r2[y], r2[x], r3[q], r4[s], r4[u], w2[x], w3[q], r1[t], r5[s], w4[u], w2[y], w5[z], r3[t], r1[q], r2[t], r5[x], r4[y], r3[u], r3[z], r1[p], r1[s], r3[p], w3[p], w5[x], w1[p], w1[q]
12
5
4
3
Example…cont.
55
12
5
4
3
r1[x], w1[x], r5[z], r2[y], r2[x], r3[q], r4[s], r4[u], w2[x], w3[q], r1[t], r5[s], w4[u], w2[y], w5[z], r3[t], r1[q], r2[t], r5[x], r4[y], r3[u], r3[z], r1[p], r1[s], r3[p], w3[p], w5[x], w1[p], w1[q]
Example…cont.
56
r1[x], w1[x], r5[z], r2[y], r2[x], r3[q], r4[s], r4[u], w2[x], w3[q], r1[t], r5[s],
w4[u], w2[y], w5[z], r3[t], r1[q], r2[t], r5[x], r4[y], r3[u], r3[z], r1[p], w1[p], r1[s], r3[p], w3[p], w5[x], w1[p], w1[q]
12
5
4
3
Example…cont.
57
r1[x], w1[x], r5[z], r2[y], r2[x], r3[q], r4[s], r4[u], w2[x], w3[q], r1[t], r5[s],
w4[u], w2[y], w5[z], r3[t], r1[q], r2[t], r5[x], r4[y], r3[u], r3[z], r1[p], w1[p], r1[s], r3[p], w3[p], w5[x], w1[p], w1[q]
12
5
4
3
Is it serializable?
Example…cont.
Concurrency Control: What? Process of managing simultaneous operations on the database without having them interfere with one another.
Prevents interference when two or more users are accessing database simultaneously and at least one is updating data.
- obtaining serializable schedules.
58
Concurrency Control ProtocolsTesting for serializability after execution
is meaningless.
Practical solution is to provide methods for ensuring serializability without performing serializability testing.
Commercially accepted protocolsLocking and TimestampsBoth are conservative approaches:
delay transactions if they conflict with other transactions.
Other protocolsOptimisticThese methods assume conflict is rare:
allow transactions to proceed unsynchronised, and only check for conflicts at commit. 59
LockingLocking is used to synchronize access by
concurrent transactions on data items.
Transaction uses locks to deny access to other transactions and so prevent incorrect updates.
A lock is a variable for a data item, that describes the status of the item with respect to allowable operations.
Example: Locking an item X for writing, prohibits other transactions from issuing a write-item (X).
60
Types of LocksBinary Locks
Simple but too restrictive
Read/Write Locks Used in commercial DBMSs
61
Binary LocksA binary lock can have 2 states:
Locked (or 1)Unlocked (or 0)
LOCK (X) has the current value of the binary lock on an item X.Item X is locked when LOCK (X) = 1Item X is unlocked when LOCK (X) = 0
When LOCK(X) = 1, other database transactions cannot perform data access operations on X.
62
Binary Locking Operationslock-item (X)B:if LOCK (X) = 0
then LOCK (X) := 1else begin wait (until LOCK (X) = 0 and lock manager wakes the transaction); go to B;end;
unlock-item (X)
LOCK (X) := 0;wakeup one of the
waiting transactions if any;
63
Binary Locking Scheme1. A transaction T must issue lock-item (X)
before any read-item (X) or write-item (X).
2. A transaction must issue unlock-item (X) after completing all read-item (X) and write-item (X).
3. A transaction T will not issue a lock-item (X) if T already holds the lock on X.
4. A transaction T will not issue unlock-item (X) unless it holds the lock on X.
64
Implementing Binary LocksDBMS has a lock manager sub-system that
keeps track of locks.Lock manager maintains:
A record of all locked items; (Item-name, LOCK, Locking-transaction)
A queue of waiting transactions.
65
Shared/Exclusive LockingOperationsMutual exclusion enforced by binary
locks is too restrictive. Several transactions should be allowed to
access X for reading.A read/write lock can have 3 states:
read-lock (shared-lock) cannot conflict, so more than one transaction
can hold read locks simultaneously on the same item.
write-lock (exclusive-lock) gives a transaction exclusive access to that
item.unlock
A record of locked items is maintained with the following fields:(item-name, LOCK, no-of-reads, locking-
transaction(s)). 66
Read/Write Locking Operations
B:if LOCK (X) = ‘unlocked’
then LOCK (X) := ‘write-
locked’else begin wait (until LOCK (X)
= ‘unlocked’ and lock manager
wakes the transaction;
go to B;end;
if LOCK (X) := ‘write-locked’
then begin LOCK (X) := ‘unlocked’; wakeup;endelse if LOCK (X) = ‘read-
locked’ then begin no-of-reads := no-of-
reads (X)-1; if no-of-reads (X) = 0 then begin LOCK (X) = ‘unlocked’; wakeup; end; end; 67
B: if LOCK (X) := ‘unlocked’then begin LOCK (X) := ‘read-locked’; no-of-reads := 1;endelse if LOCK (X) = ‘read-locked’ then no-of-reads := no-of-reads (X)+1; else begin wait (until LOCK (X) = ‘unlocked’ and lock manager wakes the transaction; go to B; end;
read-lock (X)
unlock-item (X)
write-lock (X)
Read/Write Locking Scheme1. A transaction T must issue read-lock (X) or
write-lock before any read-item (X).
2. A transaction T must issue write-lock (X) before any write-item (X).
3. A transaction must issue unlock-item (X) after completing all read-item (X) and write-item (X).
4. A transaction T will not issue a read-lock (X) if T already holds a read/write lock on X.
5. A transaction T will not issue write-lock (X) if T already holds a read/write lock on X.
6. A transaction T will not issue unlock (X) unless it already holds a read/write lock on X.
68
Shared/Exclusive Locking Scheme: Example
69
T1: r(y); r(x); x:=x+y; w(x).
T2: r(x); r(y); y:=y+x; w(y).
T1
read_lock[y]r[y]unlock[y]write_lock[x]r[x]x:=x + yw[x]unlock[x]
T2
read_lock[x]r[x]unlock[x]write_lock[y]r[y]y := x + yw[y]unlock[y]
Shared/Exclusive Locking Scheme: Example
70
Two serial schedules using locks:
A: T1 followed by T2: X = 50, Y = 80.
B: T2 followed by T1: X = 70, Y = 50.
T1
read_lock[y]r[y]unlock[y]write_lock[x]r[x]x:=x + yw[x]unlock[x]
T2
read_lock[x]r[x]unlock[x]write_lock[y]r[y]y := x + yw[y]unlock[y]
Initial Values:
X = 20, Y = 30
A nonserial schedule using locks
T1read-lock (Y);read-item (Y);unlock (Y);
write-lock (X);
read-item (X);X:=X+Y;write-item
(X);unlock (X);
71
T2
read-lock (X);read-item (X);unlock (X);write-lock (Y);read-item (Y);Y:=X+Y;write-item (Y);unlock (Y);
X unlocked too early
Y unlocked too early
Problem: Transactions release locks too soon,
resulting in the loss of total isolation and atomicity.
Final state:X = 50, Y = 50
A Nonserializable schedule
Guaranteeing Serializability: Two-Phase Locking ProtocolLocking alone does not ensure
serializability !
Positioning the locking and unlocking operations in interleaved transactions is the key task.
To guarantee serializability, an additional protocol concerning the positioning of lock and unlock operations in every transaction is needed.
Two-Phase Locking Protocol (2PL)
72
Two-Phase Protocol
A transaction follows the two-phase protocol if all locking operations precede the first unlocking operation.
73
Phase 2: Shrinking
unlock (X)unlock (Y)
Phase 1: Growing
read-lock (X)write-lock (X)write-lock (Y)
Shared/Exclusive Locking Scheme: Example
74
Two transactions obeying two-phase locking
T1
read_lock[y]r[y]write_lock[x]unlock[y] r[x]x:=x + yw[x]unlock[x]
T2
read_lock[x]r[x]write_lock[y]unlock[x]r[y]y := x + yw[y]unlock[y]
The Lost update problem
75
T1 T2
r[x] r[x]x:=x+1
x:=x-1w[x]
w[x]r[y]y:=y-1w[y]
T i m
e
x=5 x=5x:=6
x:=4 x=6
x=4 y=2y:=1 y=1
The update of the item x by T1 is lost
Preventing Lost Update problem using 2PL
76The update of the item x by T1 is not lost
T1 T2
write_lock[x]r[x]
write_lock[x] x:=x+1 waitw[x] waitwrite-lock[y] unlock[x] wait
r[x]x:=x-1w[x]unlock[x]
r[y]y:=y-1w[y]unlock[y]
The Dirty read (temporary update) Problem
77
T1 T2
r[x]x:=x+1w[x]
r[x] x:=x+2 w[x]
r[y]Abort T1
x=5 x:=6 x=6
x=6x:=8x=8
r[y]
The value of x written to the database is equal to: initial value of x + 3, while it should be x+2
Preventing Temporary Update problem using 2PL
78
T1 T2
write_lock[x]r[x]x:=x+1w[x]
write_lock[x]wait
Abort T1 r[x]
x:=x+2 w[x]
unlock[x]
The value of x written to the database is equal to: initial value of x plus 2
Variants of Two-Phase ProtocolBasic
Locking operations precede the first unlocking operation.
ConservativeLocking operations precede transaction
execution.Strict
Unlocking of write-locks after commit (or abort).Rigorous
Unlocking of all locks after commit (or abort).
79
Limitations of two-phase
Some serializable schedules may not be permitted.
Locking in general, may cause Deadlocks and Starvation.
80
Deadlocks
Each transaction in a set (of >=2 transactions) is waiting for an item which has locked another transaction in the set.
81
T1 T2
Wait-for Graph for S
T1read-lock (Y);read-item (Y);
write-lock (X);
T2
read-lock (X);read-item (X);
write-lock (Y);
Partial Schedule S
Dead Lock Handling
Only one way to break deadlock: abort one or more of the transactions.
Deadlock should be transparent to user, so DBMS should restart the aborted transactions later.
82
Dead Lock Handling contd..Two general techniques for handling
deadlock: Deadlock prevention
DBMS looks ahead to see if transaction would cause deadlock, and never allows deadlock to occur.
Deadlock detection and recovery DBMS allows deadlock to occur but recognizes
it and breaks it.
Deadlock Prevention Protocols
1. Conservative: Every transaction requires all locks before it starts. • This is a serious limitation of the concurrency.• If one lock is not available, the whole process
waits.
84
contd..2. Another protocol
Ordering all the items in the database. Lock the items according to that order if a
transaction needs several items.Also limits the concurrency. This also requires that the programmer must
be aware about the chosen order of items.
Deadlock Prevention: Using Timestamps
Transaction Timestamps – unique identifier assigned to each transaction.
Ti wants to lock an item which is currently locked by Tj
Wait-die – if TS(Ti)<TS(Tj) (Ti is older than Tj), then Ti is allowed to wait; otherwise (Ti younger than Tj) abort Ti and restart it later with the same timestamp. only an older transaction can wait for
younger one, otherwise transaction is aborted (dies) and restarted with same timestamp.
86
Deadlock Prevention: Using Timestamps
Ti wants to lock an item which is currently locked by TjWound-wait – if TS(Ti)<TS(Tj) (Ti is older the
Tj), then abort Tj (Ti wounds Tj) and restart it later with the same timestamp; otherwise (Ti younger than Tj) Ti is allowed to wait. only a younger transaction can wait for an older
one. If older transaction requests lock held by younger one, younger one is aborted (wounded).
87
Deadlock DetectionWait-for graphs showing transaction
dependencies Create a node for each transaction. Create an edge Ti -> Tj, if Ti is waiting to lock the
item locked by Tj. Deadlock exists if and only if WFG contains cycle.
WFG is created at regular intervals.Dynamic process - drop/create links.Perform system check based on given
parameters.
88
Contd..Abort deadlock causing transactions through
a ‘victim selection’ algorithms.Problem – when to check for the deadlock?A practical solution - Timeouts
Abort transactions waiting for a period longer than the system defined ‘time out’ period ( regardless of deadlock!) .
StarvationA transaction waits indefinitely, while others
continue normally. Usually the result of an unfair waiting scheme
Prevention Schemes
First come first served queue for locking requested items
Dynamic priority increase for waiting transactions or repeated ‘victims’
90
top related