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