Transaction Management, Concurrency Control and

Recovery in Relational Databases

Piyush Ojha
School of Computing and Mathematics
University of Ulster
[email protected]

23 November 2005

Abstract
Database transactions are required to be atomic, consistent, isolated and
durable. It is the programmers responsibility to define the transactions
appropriately and ensure that they are (individually) consistent. Their atomicity
must be ensured by the Database Management System (by rolling back failed
transactions). Their concurrent scheduling so that transactions remain e ectively
isolated and their durability after commit is also the responsibility of the DBMS.
We discuss serialisable, recoverable and cascadeless schedules and concurrency
control protocols for generating such schedules. Techniques for recovering from
failure are also discussed.

Transactions/ Concurrency/ Recovery

Piyush Ojha 23 November 2005

1 Sources

1. A Silberschatz, H F Korth and S Sudarshan, Database System Concepts,

4th Edition,
Chapters 15-17.
2. R El Masri and S B Navathe, Fundamentals of Database Systems, 4th
Edition,
Chapters 17-19
3. Thomas Connolly and Carolyn Begg, Database Systems: A Practical
Approach to Implementation and Management, 3rd Edition, Chapter 19.
Design,

Transactions/ Concurrency/ Recovery 1

Piyush Ojha 23 November 2005

2 Transactions

Transaction: A database transaction is a collection of database operations that

form a unit of work.
logical
Example: Transfer 100.00 from a savings account to a current account.
This is a single transaction comprising two operations:
O1: Withdraw 100.00 from the savings account.
O2: Credit 100.00 to the current account.
The two operations together constitute a unit of work.
In database transactions the most significant operations are read (i.e. data
retrieval)
write (i.e. and
update).
We will represent the money transfer transaction as follows:
Transaction T1
read(A);
A:=A-100.00;
write(A);
read(B);
B:= B+100.00;
write(B);
(A is the balance in the savings account and B the balance in the current
account.)

Transactions/ Concurrency/ Recovery 2

Piyush Ojha 23 November 2005
2.1 ACID Properties of Database Transaction

Data integrity requires that the database management system maintains the
following
properties of transactions (collectively known as ACID properties):

Atomicity: Either all operations in a database transaction are completed, or

none.
Consistency: Each transactions must maintain the consistency of the
database, i.e.consistent
it from one take state to another consistent state.

Isolation: Each transaction must be unaware of other transactions that are

executing
concurrently.

Durability: After a transaction completes successfully (commits), the changes

it makes
the to must be permanent.
database

2.1.1 Need for ACID Properties of the Example Transaction

Atomicity: Clearly, if we withdraw money from the savings account but do

not credit itaccount,
the current to the final state of the database would be inconsistent (in
the sense
it does notthat
correspond to the state of the real world). Logically, both
operations,
from withdrawl
the savings account and crediting to the current account must be
completed.
Atomicity of transactions is ensured by rolling back a transaction which is
not going successfully.
complete to This is ensured by the recovery-management
component of a DBMS.
Consistency: The database is consistent if it re ects the true state of the world.
In the transaction, the sum of the balances of the savings and current
example
accounts
the same must
beforebeand after the transactions.

(Note that at an intermediate state while the transaction is executing, for

example after has been made but before the current account is credited, the
the withdrawl
system is in an inconsistent state. The dabase management system ensures
temporarily
that these inconsistent states are not visible.)
temporarily

The programmer has the responsibility of ensuring that an individual

transaction is database management system cant ensure consistency if the
consistent. (The
programmer
withdraws 100.00 from the savings account and adds only 50.00 toe the
Isolation:
of
care.
resources
For example
When
requires
many
consider
that
transactions
thethe
actual
following
are
database
being
schedule
executed
operations
for the
concurrently,
areoperations
interleaved.cient
This
current account.)
utilisation
requires
belonging
transactions:
Transactions/
to two
Concurrency/ Recovery 3
Piyush Ojha 23 November 2005

Transaction T1 Transaction T2
read(A);
A:=A+50.00
read(A);
A:=A-100.00;
write(A);
write(A);
read(B);
B:= B+100.00;
write(B);
In this schedule the particular interleaving of database operations the
update of A byT2 is lost. The outcome is not as if
transaction T1 andwereT2isolated from each other.
Clearly, this is undesirable because the database is not consistent.
The concurrency-control component of the database management system
ensures isolation.
Durability: Once the money transfer has been completed and the account
balances
updated, the changes to the database must persist (even if there is a
subsequent system
failure).
A committed transaction can not be undone by aborting it. Its e ects can only
be
by undone
executing another conpensating transaction.
The recovery-management component of the DBMS also ensures durability
of transactions.
We will examine some of the techniques used by DBMSs to ensure atomicity,
isolation
durabilityand
of transactions.

Transactions/ Concurrency/ Recovery 4

Piyush Ojha 23 November 2005
2.2 Transaction State

Partially
Committed Committed

Active

Failed Aborted

Figure 1: State Transition Diagram for

Transaction
A transaction is

Active when it is initiated and remains so while it is executing;

Partially Committed after the final statement has been executed;
Failed after it is discovered that further execution can not proceed;
Aborted after a failed transaction has been rolled back and the database has
been
restored to an earlier consistent state;
Committed after successful execution.

Transactions/ Concurrency/ Recovery 5

Piyush Ojha 23 November 2005
2.3 Scheduling Concurrent Transactions
If each isolated transaction is consistent and the programmer has the
responsibility
ensuring this forthe simplest way of ensuring the consistency of the database
is totransactions
the execute serially, i.e. starting a transaction only when the previous one
has finished.
However this is not e cient.
Multiple transactions must run concurrently (i.e. with their operations
interleaved)
there is so that

better throughput and resource utilisation;

(Transactions require both processing and input-output. If run serially, the
CPU
be idlewould
while the transaction is reading from or writing to the backing
storage. If runone transaction can be processing the data while the other is
concurrently,
engaged
I/O.) in
reduced waiting time.
(If run serially, a short transaction may have to wait for a long time for a long
transaction to complete. Concurrent scheduling reduces the average response
time.)
Ensuring that concurrent transactions do not undermine the consistency of
data
care.requires

2.3.1 Serial and Concurrent Schedules

Consider the following transactions:

Transaction T1
read(A);
A:=A-100.00;
write(A);
read(B);
B:= B+100.00;
write(B);
Transaction T2
read(A);
temp=0.2*A;
A:=A-temp;
write(A);
read(B);
T1
B:=
write(B);
to
Transactions/
B.B+temp;
trnasfers
We will 100.00
assume
Concurrency/
that
fromtheaccount
Recovery
initial balance
A to B whereas T21000.00.
in each accounttransfers
is 20% of the balance in A
6
Piyush Ojha 23 November 2005

Transaction T1 Transaction T2
read(A);
A:=A-100.00;
write(A);
read(B);
B:= B+100.00;
write(B);
read(A);
temp=0.2*A;
A:=A-temp;
write(A);
read(B);
B:= B+temp;
write(B);

Table 1: Schedule 1: A serial schedule where T1 and T2are excuted

in that order. At the end A = 720.00 and B = 1280.00 ,A + B
is
the same before and after the transaction and the database is in a
consistent state.

Transaction T1 Transaction T2
read(A);
temp=0.2*A;
A:=A-temp;
write(A);
read(B);
B:= B+temp;
write(B);
read(A);
A:=A-100.00;
write(A);
read(B);
B:= B+100.00;
Table write(B);
executed
database
Transactions/
2: Schedule
is
before 2: AnT1
in aConcurrency/
consistent
alternative
state.
. AtRecovery
the end A =where
serial schedule 700.00 , B = 1300.00 and
T2the
is7
Piyush Ojha 23 November 2005

Transaction T1 Transaction T2
read(A);
A:=A-100.00;
write(A);
read(A);
temp=0.2*A;
A:=A-temp;
write(A);
read(B);
B:= B+100.00;
write(B);
read(B);
B:= B+temp;
write(B);

Table 3: Schedule 3: A concurrent schedule equivalent to Schedule 1.

After the transactions, A = 720.00 and B = 1280.00 .

Transaction T1 Transaction T2
read(A);
A:=A-100.00;

read(A);
temp=0.2*A;
A:=A-temp;
write(A);
read(B);

write(A);
read(B);
B:= B+100.00;
write(B);

B:= B+temp;
write(B);

Table 4: Schedule 4: A concurrent schedule that leaves the database

Conclusion:
concurrency-control
Not all
in an inconsistent concurrent
component
state. schedules
of a DBMS
At the end leave
ensures
the database
that
Aonlyinconcurrent
a consistent
= 900.00 and B = 1200.00
and
ATransactions/
+ BThe
state.
schedules
leave the database
has
thatbeen
Concurrency/
in
changed.
a consistent
Recovery
state are used. 8
Piyush Ojha 23 November 2005
2.4 Serialisability
We can ensure that a concurrent schedule leaves the database in a consistent
state by that it is equivalent to a serial schedule. (Serial schedules always
requiring
leave the in a consistent state because the consistency of individual
database
transactions is ensured
by the programmer.) Such concurrent schedules are called serialisable.
From the point of view of scheduling, the only significant database
operations
and write. are read
There are two kinds of serialisability:
con ict serialisability
view serialisability.

2.4.1 Con ict Serialisability

Consider a schedule S and two consecutive operations Ii andwhich

Ij belong to
transactions Ti and Tj respectively.
If Ii and Ij refer to di erent data, they can be swapped without a ecting the results
produced by the schedule. However, if they refer to the same data, the order
of the
operations may matter.
Consider the following four possililities:
Ii = read(Q) , Ij = read(Q)
The order doesnt matter because both transactions read the same value of Q.
Ii = read(Q) , Ij = write(Q)
Order matters; the value of Q read by Ti depends on whetheris executed
Ii before
Ij or after.
Ii = write(Q) , Ij = read(Q)
Order matter; this is really the same as the previous case with roles of Ij
Ii
and
reversed.
Ii = write(Q) , Ij = write(Q)
Order matters; it does not a ect Ti or Tj but a ects the value of read by Q
subsequent operations in S , or if there are no subsequent reads, the final value ofQ
written to the datanase.

Thus the relative order of Ii and Ij matters if they operate on the same data item and at
least one operation is a write. In this case, Ii and Ij are said to con ict.
IfTransactions/
operations,
Cona schedule SConcurrency/
SandcanSbe are
ict Serialisability
Equivalence transformed
Recovery
said to beinto
con anther
ict equivalent.
schedule by Sswapping non-con icting9
Piyush Ojha 23 November 2005

A schedule S is con ict serialisable if it is con ict equivalent to a serial schedule.

Clearly a con ict-serialisable schedule leaves the database in a consistent

state.

Examples

Example 1

Transaction T1 Transaction T2
read(A);
write(A);
read(B);
write(B);
read(A);
write(A);
read(B);
write(B);

Table 5: Schedule 1 with only read and write statements shown.

Transaction T1 Transaction T2
read(A);
write(A);
read(A);
write(A);
read(B);
write(B);
read(B);
write(B);

Table 6: Schedule 3 showing only read and write operations. read(A)

and write(A) operations in T2 can be swapped with read(B) and write(B)
operations
and
Example
Transactions/
therefore T1
2 in conflict . The Recovery
Concurrency/ schedule is conflict equivalent to Schedule 1
serialisable. 10
Piyush Ojha 23 November 2005

Transaction T3 Transaction T4
read(A);
write(A);
write(A);

Table 7: Schedule 5: A non-conflict-serialisable schedule. The

two write operations can not be swapped, so the schedule can not be
transformed into the serial schedule ( T3; T4 ). Similarly, because
T3 : read(A) can not be swapped with T4 : write(A) , it can not be
transformed into the serial schedule ( T4; T3 ).
Notice the blind write (i.e. a write without a read) in T3 .
Example 3

Transaction T1 Transaction T5
read(A);
A:=A-100.00;
write(A);

read(B);
B:=B-50.0;
write(B);

read(B);
B:= B+100.00;
write(B);

read(A);
A:= A+50.0;
write(A);

Table 8: Schedule 6: A concurrent schedule that is not conflict

serialisable (Exercise: Why?) but still leaves the database in a
consistent state
The last example shows that con ict serialisability is su cient but not
necessary for
ensuring consistentcy of the database. Nevertheless, it is simpler to require all
concurrent
schedules to be con ict-serialisable.
View serialisability is also based only on read and write operations but it is
2.4.2
less
than
Transactions/
stringent
con
View
ictSerialisability
serialisability.
Concurrency/ Recovery 11
Piyush Ojha 23 November 2005

Schedules S and S comprising the same set of transactions are said to be view equivalent
if the following conditions are satisfied:

1. For each data item Q , if transaction Ti reads the initial value ofin theQschedule
S , it must also read the initial value of Q in S .
2. For every data item Q , if the value of Q read by Ti was S
in previously written by
Tj , the value of Q read by Ti in S must also have been previously written byTj.
3. For every data item Q , the final value must be written to the database by the same
transaction in both schedules.

Conditions 1 and 2 ensure that every transaction reads the same data in the
two schedules.
Likewise, the third condition ensures that both schedules make the same
updates
database.to the
A concurrent schedule is view serialisable if it is view equivalent to a serial
schedule.
Example

Transaction T3 Transaction T4 Transaction T6

read(A);
write(A);
write(A);
write(A);

Table 9: Schedule 7: A non-conflict-serialisable schedule thatb is

view-serialisable. The schedule is view-equivalent to ( T3; T4 ; T6
).

Every con ict-serialisable schedule is also view-serialisable.

Every view-serialisable schedule that is not con ict-serialisable has blind
writes.

2.4.3 Testing for Con ict Serialisability

Concurrency control modules of DBMSs are designed to generate con ict-

serialisable
schedules but it is still useful to be able to test a given schedule for con ict
serialisability. S
This can be done easily by constructing a precedence graph for a given . The
schedule
precedence graph contains a vertex (or a no de) for each transactions and a
number
directed of
edges as follws.
For each pair of transactions Ti and Tj , there is a directed edge from Tiif any
to Tj
of
the following conditions holds:
Ti executes
Transactions/ read(Q) Recovery
write(Q)
Concurrency/ before TjTj executes
before executes write(Q)
read(Q) ; ;
write(Q) 12
Piyush Ojha 23 November 2005

If there is a directed edge from Ti to Tj , then Ti must come beforein any

Tjequivalent
serial schedule.
It follows that the schedule is con ict serialisable if and only if its precedence
graph does any cycles.
not contain
Examples
Schedule 3
T1 : r1(A); w1 (A); r1 (B); w1(B);
T2 : r2(A); w2 (A); r2 (B); w2(B);
(Here ri(A) and wi (A) are read and write operation respectively on A
by transaction
Ti .)
S : r1 (A); w1(A); r2(A); w2(A); r1(B); w1 (B); r2(B); w2 (B) .

T T
1 2

Figure 2: Precedence graph for Schedule 3

The precedence graph has no cycles, so the schedule is con ict serialisable.
Schedule 4
T1 : r1(A); w1 (A); r1 (B); w1(B);
T2 : r2(A); w2 (A); r2 (B); w2(B);
S : r1 (A); r2 (A); w2(A); r2 (B); w1(A); r1(B); w1(B); w2 (B) .

T T
1 2

Figure 3: Precedence graph for Schedule 4

Transactions/ Concurrency/ Recovery 13

Piyush Ojha 23 November 2005
2.5 Recoverability
When S is con ict-serialisable and all transactions commit, the database is left in a
consistent state.
What if one of the transactions (say Ti ) fails?
We must rollback Ti as well as all other transactions that have read data written by Ti.
Recoverable Schedules

Transaction T1 Transaction T2
read(A);
write(A);
read(A);
write(A);
commit;
read(B);
write(B);

Table 10: A non-recoverable schedule.

In the above schedule, T2 commits immediately after writing A. If failsT1
subsequently,
we must roll back T1 as well as T2 (because it reads the value of Awritten T1
by
).
However, T2 cant be rolled back because it has already committed. The schedule is
non-recoverable.
A schedule is recoverable if, for every pair of transaction Ti and Tj where
readsTja
data item previously written by Ti , Ti commits before Tj .
Clearly concurrent schedules should be con ict-serialisable and recoverable.
Even when a schedule is recoverable, the failure of one transaction may
cause
severalrollback of (cascading rollback) and therefore wasted work. For
transactions
example

Transaction T1 Transaction T2 Transaction T3

read(A);
read(B);
write(A);
read(A);
write(A);
read(A);
write(A);
T1
Table T2
Transactions/
, 11:
write(B)
Aand T3 with
schedule
Concurrency/
to bea rolled
cascading
Recovery
back.rollback. Failure of T1
causes
14
Piyush Ojha 23 November 2005

Cascadeless Schedule
A concurrent schedule is cascadeless if, for every pair of transactions Ti and Tj
such that
Tj reads a data item previously written by Ti , commits
Ti before the read operation of
Tj .
Every cascadeless schedule is also recoverable.

Transactions/ Concurrency/ Recovery 15

Piyush Ojha 23 November 2005

3 Concurrency Control

In this section we consider protocols for generating serialisable concurrent

schedules. This
is su cient to ensure e ective isolation of transactions.
We will consider two kinds of proto cols:

Lo ck-based protocols
Timestamp-based protocols

Transactions/ Concurrency/ Recovery 16

Piyush Ojha 23 November 2005
3.1 Lock-Based Protocols
In these protocols, a transaction is given access to a data item only if it holds
a lock on it.
There are two kinds of locks:

Shared: A transaction Ti holding a shared lock on a data item can read Q it but not
write it. Other transactions can simultaneously hold a shared lock on the data
item.
Exclusive: A transaction holding an exclusive lock on a data item can read as
well
writeasit. Only one transaction can hold an exclusive lock on a data ite at a
time.
A transaction

requests an appropriate lock from the lo ck manager when it needs access to a

data
item,
proceeds with the operation when the lo ck is granted, and
releases the lock when access is no longer required.

A lo ck is granted only if no other transaction holds an incompatible lock on

the data item.
( A shared lo ck is compatible with a shared lock but incompatible with an
exclusive lock.lo ck is incompatible with both shared and exclusive locks.)
An exclusive
A transaction has to wait till a lock it has requested can be granted.
In the following, we include lo ck and unlock requests as part of the
transaction
is a request (lock
for anX(A)
exclusive lock on A, lock S(A) is a request for a shared
lock and releases the lock).
unlock(A)
Transaction T1
lock X(A);
read(A);
A:=A-100.00;
write(A);
unlock(A);
lock X(B);
read(B);
B:= B+100.00;
write(B);
unlock(B);
Transaction T2
lock S(A);
lock
unlock(A);
read(A);
read(B);
Transactions/
S(B); Concurrency/ Recovery 17
 Piyush Ojha 23 November 2005

unlock(B);
print(A+B);
T1 transfers 100.00 from the savings account (A) to the current account; printsT2
the
value of A + B .
Notice that both transactions release a lo ck as soon as they have finished
using
item. a data
This is not a good idea because it allows concurrent schedules that are not
serialisable. For 1 below.
example, Schedule

Transaction T1 Transaction T2 Lock Manager

lock X(A)
grant X(A, T1 );
read(A);
A:=A-100.00;
write(A);
unlock(A);
lock S(A);
grant S(A, T2 );
read(A);
unlock(A);
htb!
lock S(B);
grant S(B, T2 );
read(B);
unlock(B);
print(A+B);
lock X(B)
grant X(B, T1 );
read(B);
B:= B+100.00;
write(B);
unlock(B)

Table 12: Schedule 1: A concurrent schedule for transactions T1,

T2 and the lock manager. If A = B = 1000.00 at the start of the
transactions, T2 prints 1900.00 instead of 2000.00 printed by either
of the serial schedules (T1 , T2) or (T2 , T1 ) . This schedule is not
serialisable and leaves
and lock releases. the database
In particular, all loinck
anrequests
inconsistent state before
are made becauseany locks
T1
We
are
Transaction
Transactions/
released.
now
releases
change
theT3
Concurrency/
the
lock
transactions
on A too early. T1 and T2
Recovery slightly and alter the order of lock requests18
Piyush Ojha 23 November 2005

lock X(A);
read(A);
A:=A-100.00;
write(A);
lock X(B);
unlock(A);
read(B);
B:= B+100.00;
write(B);
unlock(B);

Transaction T4

lock S(A);
read(A);
lock S(B);
unlock(A);
read(B);
unlock(B);
print(A+B);

This seemingly small change has a profound e ect on the concurrent

schedules.
concurrent
Transactions/
Any
schedule T3
Concurrency/
for and T4 is guaranteed to be serialisable.
Recovery 19
Piyush Ojha 23 November 2005

Transaction T3 Transaction T4 Lock Manager

lock X(A)
grant X(A, T1 );
read(A);
A:=A-100.00;
write(A);
lock S(A);
lock X(B)
grant X(B, T1 );
unlock(A);
grant S(A, T2 );
htb!
read(A);
lock S(B);
read(B);
B:= B+100.00;
write(B);
unlock(B)
grant S(B, T2 );
unlock(A);
read(B);
unlock(B);
print(A+B);

Table 13: Schedule 2: A concurrent schedule for transactions T4,

T3
and the lock manager. T4 has to wait for the locks it requests. The
schedule is actually equivalent to the serial schedule (T1, T2) and
T2
prints the correct result A + B = 2000.0 . In fact, every concurrent
schedule for T3 and T4 is serialisable. The equivalent serial order
is the order in which the transactions make their last lock request.

Deadlock

Lo
Transactions/
ck-based protocols
Concurrency/
can lead
Recovery
to a deadlock. 20
Piyush Ojha 23 November 2005

Transaction T3 Transaction T5 Lock Manager

lock X(A)
grant X(A, T1 );
read(A);
A:=A-100.00;
htb! write(A);
lock S(B)
grant S(B, T2 );
read(B);
lock S(A);
lock X(B)

Table 14: Schedule 2: A deadlocked concurrent schedule. T5 is

waiting for T3 to release its exclusive lock of A and T3 is waiting
for T5 to release its shared lock on B. One of the transactions must be
rolled back.
When a deadlo ck o ccurs, one of the deadlo cked transactions must be rolled
back. Its locks
are released and other transactions can proceed.
Locking Protocol
A locking protocol is a set of rules which determine when a transaction may
lo ck ck
unlo anddata items. A lo cking proto col ensures con ict serialisability if every
concurrent
schedule generated under the locking proto col is con ict serialisable.

3.1.1 The Two-Phase Locking Protocol

Every transaction requests locks and releases locks in two phases, a growing
phase and phase.
shrinking a

In the growing phase, a transaction may request lo cks but may not release
any lo cks.
In the shrinking phase, a transaction may release lo cks but may not request
any new lo cks.
Transactions T3 and T4 in the previous example conform to the two-phase locking protocol.
The two-phase locking protocol has the following properties:

It ensures serialisability.
The equivalent serial order is the order in which the transactions make their
last
request for
Transactions/
It
example
Cascading
does not a lock (i.e.
conform
Concurrency/
rollbacks
guarantee
to thethe
may orderfrom
freedom
Recovery
two-phase
occur. in which their
locking
deadlock. growing
protocol, yetphase
Transactions ends).
end up T3 cked.
deadlo andtheT5
in previous
21
Piyush Ojha 23 November 2005

Strict Two-Phase Locking

In addition to two-phase locking, all exclusive locks are held till the
transaction commits.
Therefore data written by an uncommitted transaction is not read by other
transactions tillcommits.
the transaction
Therefore, if a transaction fails, no other transaction has to be rolled back
because no
other transaction has read any data written by the failed transaction.
The corresponding concurrent schedules are therefore cascadeless.
Rigorous Two-Phase Locking
In this variant of two-phase locking, all locks are held till a transaction
commits.
The equivalent serial order is the order in which the transactions commit.

Transactions/ Concurrency/ Recovery 22

Piyush Ojha 23 November 2005
3.2 Timestamp-Based protocols
These protocols e ectively determine the serialisability order of transactions
in advance.
With each transaction Ti is asso ciated a unique timestamp, T S(Ti) .
The timestamp is assigned before the transaction starts execution.
The timestamp may be taken from the system clock or from a counter which
is incremented
every time a new timestamp is assigned.
The timestamp order determines the serialisability order of transactions.
The system also assigns TWO timestamps to each data item. a write-
timestamp and a(denoted WTS and RTS respectively).
read-timestamp
WTS(A) is the timestamp of the last transaction that wrote A.
RTS(A) is the largest timestamp of any transactions which read A
successfully.

3.2.1 The Timestamp-Ordering Protocol

The timestamp-ordering proto col ensures that read and write operations are
executed
timestampinorder.
The rules of this proto col are as follows:

1. When Ti wants to read(A)

If T S(Ti ) < W T S(A) , A has already been written by a later transaction
Ti is rolled back
If T S(Ti) = W T S(A) , Ti is allowed to read A and RT S(A)
is updated to
the larger of RT S(A) and T S(Ti )
2. When Ti wants to write(A)
If T S(Ti ) < RT S(A) , A has been read by a later transaction
Ti is rolled back
If T S(Ti ) < W T S(A) , A has been written by a later transaction.
Ti is rolled back
If T S(Ti ) = RT S(A) and T S(Ti) = W T S(A) Ti
is,allowed to write A
and W T S(A) is updated to T S(Ti) .

When a transaction is rolled back, it is restarted with a new timestamp.

The timestamp-ordering protocol guarantees con ict serialisability because
con icting are executed in timestamp order.
operations
It is free
Long transactions
from deadlocks
may bebecause
starvedno
if they
transaction
are repeatedly
ever hasrolled
to wait
back
for because
a data
item.
of
short
Transactions/
contransactions.
icting Concurrency/ Recovery 23