database systems: transaction management
DESCRIPTION
Database Systems: Transaction Management. Necessity. Database systems are normally being accessed by many users or processes at the same time. Both queries and modifications. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/1.jpg)
1
Database Systems: Transaction Management
![Page 2: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/2.jpg)
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.
![Page 3: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/3.jpg)
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?
![Page 4: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/4.jpg)
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
![Page 5: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/5.jpg)
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
![Page 6: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/6.jpg)
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
![Page 7: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/7.jpg)
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
![Page 8: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/8.jpg)
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
![Page 9: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/9.jpg)
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
![Page 10: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/10.jpg)
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
![Page 11: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/11.jpg)
11
Active
Failed
Committed
Terminated
Partially Committed
begin-transaction commit
read-item, write-item
abortabort
end-transaction
STATE
Transition
![Page 12: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/12.jpg)
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]
![Page 13: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/13.jpg)
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]
![Page 14: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/14.jpg)
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
![Page 15: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/15.jpg)
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
![Page 16: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/16.jpg)
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
![Page 17: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/17.jpg)
!!! Concurrency ProblemsLost updateDirty readIncorrect summaryUnrepeatable Read
17
![Page 18: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/18.jpg)
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
![Page 19: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/19.jpg)
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
![Page 20: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/20.jpg)
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
![Page 21: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/21.jpg)
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
![Page 22: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/22.jpg)
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
![Page 23: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/23.jpg)
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
![Page 24: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/24.jpg)
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
![Page 25: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/25.jpg)
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
![Page 26: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/26.jpg)
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
![Page 27: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/27.jpg)
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
![Page 28: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/28.jpg)
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
![Page 29: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/29.jpg)
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
![Page 30: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/30.jpg)
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
![Page 31: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/31.jpg)
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
![Page 32: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/32.jpg)
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
![Page 33: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/33.jpg)
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.
![Page 34: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/34.jpg)
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
![Page 35: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/35.jpg)
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
![Page 36: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/36.jpg)
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
![Page 37: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/37.jpg)
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
![Page 38: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/38.jpg)
38
RecoverabilityAvoidance of
cascading rollback
Strictness
![Page 39: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/39.jpg)
Characterising Schedules Based on SerializabilityCharacterise the type of schedules
that are considered correct when concurrent transactions are executing.Serial schedulesNonserial schedulesConflict-Serializable schedules
39
![Page 40: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/40.jpg)
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
![Page 41: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/41.jpg)
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)
![Page 42: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/42.jpg)
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)
![Page 43: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/43.jpg)
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).
![Page 44: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/44.jpg)
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
![Page 45: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/45.jpg)
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
![Page 46: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/46.jpg)
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
![Page 47: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/47.jpg)
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
![Page 48: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/48.jpg)
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);…;
![Page 49: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/49.jpg)
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
![Page 50: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/50.jpg)
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
![Page 51: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/51.jpg)
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
![Page 52: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/52.jpg)
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
![Page 53: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/53.jpg)
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
![Page 54: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/54.jpg)
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.
![Page 55: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/55.jpg)
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.
![Page 56: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/56.jpg)
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.
![Page 57: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/57.jpg)
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.
![Page 58: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/58.jpg)
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
![Page 59: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/59.jpg)
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
![Page 60: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/60.jpg)
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
![Page 61: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/61.jpg)
Types of LocksBinary Locks
Simple but too restrictive
Read/Write Locks Used in commercial DBMSs
61
![Page 62: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/62.jpg)
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
![Page 63: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/63.jpg)
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
![Page 64: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/64.jpg)
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
![Page 65: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/65.jpg)
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
![Page 66: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/66.jpg)
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
![Page 67: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/67.jpg)
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)
![Page 68: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/68.jpg)
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
![Page 69: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/69.jpg)
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]
![Page 70: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/70.jpg)
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
![Page 71: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/71.jpg)
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
![Page 72: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/72.jpg)
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
![Page 73: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/73.jpg)
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)
![Page 74: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/74.jpg)
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]
![Page 75: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/75.jpg)
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
![Page 76: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/76.jpg)
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]
![Page 77: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/77.jpg)
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
![Page 78: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/78.jpg)
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
![Page 79: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/79.jpg)
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
![Page 80: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/80.jpg)
Limitations of two-phase
Some serializable schedules may not be permitted.
Locking in general, may cause Deadlocks and Starvation.
80
![Page 81: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/81.jpg)
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
![Page 82: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/82.jpg)
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
![Page 83: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/83.jpg)
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.
![Page 84: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/84.jpg)
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
![Page 85: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/85.jpg)
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.
![Page 86: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/86.jpg)
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
![Page 87: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/87.jpg)
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
![Page 88: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/88.jpg)
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
![Page 89: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/89.jpg)
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!) .
![Page 90: Database Systems: Transaction Management](https://reader035.vdocument.in/reader035/viewer/2022062517/56813686550346895d9e0f55/html5/thumbnails/90.jpg)
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