Transaction Concept

s vishnu murthy , M.Tech.,(Ph.D)

 Transaction Concept
• A Transaction is an execution of user program and seen by
the DBMS as series of actions i.e READ and WRITE
operations to the DATABASE
• E.g. transaction to transfer $50 from account A to account
B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
• Two main issues to deal with:
– Failures of various kinds, such as hardware failures
and system crashes
– Concurrent execution of multiple transactions

s vishnu murthy , M.Tech.,

(Ph.D)
 ACID Properties

• Atomicity. Either all actions of a transaction are carried out

or none of then are carried out.
• Consistency. If the database is in consistent state before the
execution of a transaction, it must remain consistent after
execution of the transaction also.
• Isolation. Although multiple transactions may execute
concurrently, each transaction must be unaware of other
concurrently executing transactions. Intermediate
transaction results must be hidden from other concurrently
executed transactions.
– That is, for every pair of transactions Ti and Tj, it appears
to Ti that either Tj, finished execution before Ti started, or Tj
started execution after Ti finished.
• Durability. After a transaction completes successfully, the
changes it has made to the database must persist, even if
there are system failures.
s vishnu murthy , M.Tech.,(Ph.D)
 Transaction States
• Active – the initial state; the transaction stays in this state
while it is executing
• Partially committed – after the final statement has been
executed.
• Failed -- after the discovery that normal execution can no
longer proceed.
• Aborted – after the transaction has been rolled back and the
database restored to its state prior to the start of the
transaction. Two options after it has been aborted:
– restart the transaction
• can be done only if no internal logical error
– kill the transaction
• Committed – after successful completion.

s vishnu murthy , M.Tech.,(Ph.D)

Transaction States

s vishnu murthy , M.Tech.,

(Ph.D)
 Implementation of Atomicity and Durability
• The recovery-management component of a database system
implements the support for atomicity and durability.
• E.g. the shadow-database scheme which is extremely inefficient
and can not handle large databases.
• A pointer called db-pointer maintained on disk and points to the
current copy of the database.

• In a shadow copy scheme , the transaction that wants to update the

database creates a complete copy of the database.
• All the updates are done on the new copy ,leaving the original copy
(shadow copy) un touched.
• If at any time the transaction has been aborted, the system merely
deletes the new copy.The old copy of the database has been not
affected.
• If the transaction completes ,the OS makes sure that all pages of
the new database copy have been written to disk.
• And the DB-pointer is made to point to the new copy of the
database.

s vishnu murthy , M.Tech.,

(Ph.D)
s vishnu murthy , M.Tech.,
(Ph.D)
 – In case transaction fails, old consistent copy pointed
to by db_pointer can be used, and the new copy can
be deleted.
• The shadow-database scheme:
– Assumes that only one transaction is active at a time.
– Assumes disks do not fail
• extremely inefficient for large databases
– Variant called shadow paging reduces copying of
data, but is still not practical for large databases
– Does not handle concurrent transactions

s vishnu murthy , M.Tech.,

(Ph.D)
Concurrent Execution of transactions
• Multiple transactions are allowed to run concurrently
in the system. The DBMS interleaves the actions of
different transactions to improve performance.
Motivation for concurrent execution
1. Improved throughput and resource utilization
E.g. one transaction can be using the CPU
while another is reading from or writing to
the disk
so multiple transactions executing in
parallel can keep the CPU and I/O devices
busy leading to maximum throughput.
2. Reduced waiting time for transactions: short
transactions need not wait behind long ones.

s vishnu murthy , M.Tech.,

(Ph.D)
Serialiazabilty: A serializable schedule over a set
S of committed transactions is a schedule whose
effect on any consistent database is guaranteed to
be identical to that of some complete serial
schedule over S. Example :
T1 T2
R(A)
A
W(A)
schedule
R(A)
W(A)
R(B)
W(B)
R(B)
W(B)
COMMIT
COMMIT s vishnu murthy , M.Tech.,
(Ph.D)
 Anomalies due to interleaved execution

There are 3 main situations when the actions of two transactions

conflict with each other in the interleaved execution of the same
object.
1. Write-Read(WR) conflict- reading uncomitted data.
2. Read-Write(RW) conflict-unrepeatable reads
3. Write-Write(WW) conflict-over writing uncommited data.

WR conflict:- A transaction T2 could read a database object A that

has just been modified by another transaction t1 which has not
yet committed. Such a read is called dirty read.
Suppose Transaction t1 has to transfer $100 from A to B and T2
increments both A and Bs accounts by 6%

s vishnu murthy , M.Tech.,

(Ph.D)
EXAMPLE OF DIRTY READ

T1 T2
R(A)
A:=A-100
W(A)
R(A) R(A)-dirty read
A:=A+0.06*A
W(A)
R(B)
B:=B+B*0.06

W(B)
COMMIT
R(B)
B:=B+100
W(B)
COMMIT s vishnu murthy , M.Tech.,
(Ph.D)
UNREPEATABLE READS:- transaction t2 could change the value of
an object A that has been read by a transaction t1 and t1 is still in
progress.
It causes a problem that if T1 tries to read the values of A again ,it
will get a different result.

Overwriting uncommitted data:-a transaction t2 could overwrite

the value of an object A which has already been modified by a
transaction t1 and t1 is still in progress.
Suppose that A and B are two employees and their salaries must be
kept equal.T1 sets these salaries to $1000 and t2 sets them to
$2000.
The following interleaving occurs
T1 sets A’s sal to $1000 , at the same time t2 sets B’s sal to $2000
T1 sets B’s sal to $1000 at the same time t2 sets A’s sal to $2000.
The result is A’s sal is $2000 and B’s sal is $1000 and they are not
identical.
s vishnu murthy , M.Tech.,
(Ph.D)
 Schedules
• Schedule – a sequences of instructions that specify the
chronological order in which instructions of concurrent
transactions are executed
– a schedule for a set of transactions must consist of all
instructions of those transactions
– must preserve the order in which the instructions
appear in each individual transaction.
• A transaction that successfully completes its execution
will have a commit instructions as the last statement
– by default transaction assumed to execute commit
instruction as its last step
• A transaction that fails to successfully complete its
execution will have an abort instruction as the last
statement

s vishnu murthy , M.Tech.,

(Ph.D)
 Example of serial Schedule
• Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance
from A to B.
• A serial schedule in which T1 is followed by T2 :

s vishnu murthy , M.Tech.,

(Ph.D)
 Example -Concurrent schedule
• Let T1 and T2 be the transactions defined previously. The following
schedule2 is not a serial schedule, but it is equivalent to Schedule 1.

In Schedules 1, 2 ,the sum A + B is preserved.

s vishnu murthy , M.Tech.,
(Ph.D)
 Serializability
• A concurrent schedule is serializable if it is
equivalent to a serial schedule. Different
forms of schedule equivalence give rise to the
notions of:
1. conflict serializability
2. view serializability

s vishnu murthy , M.Tech.,

(Ph.D)
 Conflicting Instructions√
• Instructions li and lj of transactions Ti and Tj respectively,
conflict if and only if there exists some item Q accessed by
both li and lj, and at least one of these instructions write Q.
1. li = read(Q), lj = read(Q). li and lj don’t conflict.
2. li = read(Q), lj = write(Q) the order matters
3. li = write(Q), lj = read(Q). The order matters
4. li = write(Q), lj = write(Q). They conflict as the value of
the next read(Q) operation is affected since the result of the
latter write instruction is only preserved in the database.

• If li and lj are consecutive instructions of different

transactions in a schedule and they do not conflict, then
we can swap the order of these two instructions to produce
a new schedule S’.we Expect S to be equivalent to S’ since
all instructions appear in same order except Ii and Ij whose
order does not matter.

s vishnu murthy , M.Tech.,

(Ph.D)
 T1 T2
Read(A)
Write(A)
Read(A)
Write(A)
Read(B)
Write(B)
Read(B)
Write(B)

In the above schedule, The write(A) of T2 does not conflict with

read(B) of T1.so we can swap these two to generate an equivalent
schedule as below

s vishnu murthy , M.Tech.,

(Ph.D)
T1 T2
Read(A)
Write(A)
Read(A)
Read(B)

Write(A)
Write(B)
Read(B)
Write(B)

After swapping

s vishnu murthy , M.Tech.,

(Ph.D)
 Conflict Serializability√

• If a schedule S can be transformed into a schedule S´ by a

series of swaps of non-conflicting instructions, we say that S
and S´ are conflict equivalent.
• We say that a schedule S is conflict serializable if it is conflict
equivalent to a serial schedule

s vishnu murthy , M.Tech.,

(Ph.D)
 Conflict Serializability √
• Schedule 3 can be transformed into Schedule 6, a serial
schedule where T2 follows T1, by series of swaps of non-
conflicting instructions.
– Therefore Schedule 3 is conflict serializable.

Schedule 3 Schedule 6
s vishnu murthy , M.Tech.,
(Ph.D)
 Conflict Serializability√
• Example of a schedule that is not conflict serializable:

• We are unable to swap instructions in the above schedule to

obtain either the serial schedule < T3, T4 >, or the serial
schedule < T4, T3 >.

s vishnu murthy , M.Tech.,

(Ph.D)
 View Serializability(ok)
• Let S and S´ be two schedules with the same set of
transactions. S and S´ are view equivalent if the following
three conditions are met, for each data item Q,
1. For each data item Q ,If in schedule S, transaction Ti
reads the initial value of Q, then in schedule S’ also
transaction Ti must read the initial value of Q.
2. If in schedule S transaction Ti executes read(Q), and that
value was produced by transaction Tj (if any), then in
schedule S’ also transaction Ti must read the value of Q
that was produced by the same write(Q) operation of
transaction Tj .
3. The transaction (if any) that performs the final write(Q)
operation in schedule S must also perform the final
write(Q) operation in schedule S’.
As can be seen, view equivalence is also based purely on reads
and writes alone.

s vishnu murthy , M.Tech.,

(Ph.D)
 View Serializability
• A schedule S is view serializable if
it is view equivalent to a serial
schedule.
• Every conflict serializable schedule
is also view serializable.
•

s vishnu murthy , M.Tech.,

(Ph.D)
 Recoverable Schedules
Need to address the effect of transaction failures on concurrently
running transactions.
• Recoverable schedule — if a transaction Tj reads a data
item previously written by a transaction Ti , then the
commit operation of Ti appears before the commit
operation of Tj.
• The following schedule is not recoverable if T9 commits
immediately after the read

• If T8 should abort, T9 would have read an inconsistent database

state. Hence, database must ensure that schedules are
recoverable.

s vishnu murthy , M.Tech.,

(Ph.D)
 Cascading Rollbacks
• Cascading rollback – a single transaction failure leads to
a series of transaction rollbacks. Consider the following
schedule where none of the transactions has yet
committed (so the schedule is recoverable)

• If T10 fails, T11 and T12 must also be rolled back.

• Can lead to the undoing of a significant amount of work

s vishnu murthy , M.Tech.,

(Ph.D)
 Implementation of Isolation
• Schedules must be conflict or view serializable, and
recoverable, for the sake of database consistency, and
preferably cascadeless.
• A policy in which only one transaction can execute at a time
generates serial schedules, but provides a poor degree of
concurrency.
• Concurrency-control schemes tradeoff between the amount of
concurrency they allow and the amount of overhead that they
incur.
• Some schemes allow only conflict-serializable schedules to be
generated, while others allow view-serializable schedules that
are not conflict-serializable.

s vishnu murthy , M.Tech.,

(Ph.D)
 Figure 15.6

s vishnu murthy , M.Tech.,

(Ph.D)
 Testing for Serializability
• Consider some schedule of a set of transactions T1, T2, ...,
Tn
• Precedence graph — a direct graph where the vertices are
the transactions (names).
• We draw an arc from Ti to Tj if the two transaction conflict,
and Ti accessed the data item on which the conflict arose
earlier.
• We may label the arc by the item that was accessed.
• Example 1
x

s vishnu murthy , M.Tech.,

(Ph.D)
 Example Schedule (Schedule A) + Precedence Graph

T1 T2 T3 T4 T5
read(X)
read(Y)
read(Z)
read(V)
read(W)
read(W) T1 T2
read(Y)
write(Y)
write(Z)
read(U)
read(Y)
write(Y)
read(Z)
T3 T4
write(Z)
read(U)
write(U)

T5

s vishnu murthy , M.Tech.,

(Ph.D)
 Test for Conflict Serializability
• A schedule is conflict serializable if and only
if its precedence graph is acyclic.
• Cycle-detection algorithms exist which take
order n2 time, where n is the number of
vertices in the graph.
– (Better algorithms take order n + e where
e is the number of edges.)
• If precedence graph is acyclic, the
serializability order can be obtained by a
topological sorting of the graph.
– This is a linear order consistent with the
partial order of the graph.
– For example, a serializability order for
Schedule A would be
T5  T1  T3  T2  T4
• Are there others?

s vishnu murthy , M.Tech.,

(Ph.D)
 Test for View Serializability
• The precedence graph test for conflict serializability
cannot be used directly to test for view serializability.
– Extension to test for view serializability has cost
exponential in the size of the precedence graph.
• The problem of checking if a schedule is view serializable
falls in the class of NP-complete problems.
– Thus existence of an efficient algorithm is extremely
unlikely.
• However practical algorithms that just check some
sufficient conditions for view serializability can still be
used.

s vishnu murthy , M.Tech.,

(Ph.D)
 Concurrency control and Lock Based protocols

One way to achieve serializability is to require that

data items be accessed in a mutually exclusive
manner.i.e when one transaction is accessing a data
item, no other transaction can modify that data
item.
The most common method to implement this rule is
To allow a transaction to access a data item only if
it is holding a lock on that item currently.

s vishnu murthy , M.Tech.,

(Ph.D)
 Lock-Based Protocols
• A lock is a mechanism to control concurrent
access to a data item
• Data items can be locked in two modes :
1. exclusive (X) mode. Data item can be both read
as well as written. X-lock is requested using
lock-X instruction.
2. shared (S) mode. Data item can only be read. S-
lock is requested using lock-S instruction.
• Lock requests are made to concurrency-control
manager. Transaction can proceed only after
request is granted.

s vishnu murthy , M.Tech.,

(Ph.D)
 Lock-Based Protocols
• Lock-compatibility matrix

• A transaction may be granted a lock on an item if the requested

lock is compatible with locks already held on the item by other
transactions
• Any number of transactions can hold shared locks on an item,
– but if any transaction holds an exclusive on the item no other
transaction may hold any lock on the item.
• If a lock cannot be granted, the requesting transaction is made to
wait till all incompatible locks held by other transactions have
been released. The lock is then granted.

s vishnu murthy , M.Tech.,

(Ph.D)
 Lock-Based Protocols
• Example of a transaction performing locking:
T2: lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
display(A+B)
• If we do not use locking or if we unlock data items as soon as
possible after reading or writing ,we may get inconsistent
states.on the other hand, if we do not unlock a data item
before we request a lock, deadlocks may occur.
• A set of rules followed by all transactions must be followed
while requesting and releasing locks which are called Locking
protocols. Locking protocols restrict the set of possible
schedules.
s vishnu murthy , M.Tech.,
(Ph.D)
 The Two-Phase Locking Protocol
• This is a protocol which ensures serializability.In this each
transaction issues lock and unlock requests in two phases.
• Phase 1: Growing Phase
– transaction may obtain locks
– transaction may not release locks
• Phase 2: Shrinking Phase
– transaction may release locks
– transaction may not obtain locks
• Initially the transaction is in growing phase. once the
transaction releases a lock ,it enters the shrinking phase
and it can not issue any lock requests.

s vishnu murthy , M.Tech.,

(Ph.D)
 Cascading rollbacks

T10 T11 T12

Read(A)
Read(B)
Write(A)
Read(A)
Write(A)
Read(A)

T10 writes a A which is read by transaction T11.T11 writes A

which is read by T12.at this point of T10 fails , T10 must be
rolled back since T11 is dependent on T10 ,T11 must be rolled
back. In the same way T12 must also be rolled back.
This is called Cascading rollback.

s vishnu murthy , M.Tech.,

(Ph.D)
 Dead Locks
T3 T4
Lock-X(B)
Read(B)
B:=B-50
Write(B)
Lock-S(A)
Read(A)
Lock-S(B)
Lock-X(A)

T3 is holding X lock on B ,T4 is requesting S lock on B so T4 is

waiting for T3 to unlock B. Similarly T3 is waiting for T4 to unlock
A.and neither of them proceed with normal execution.
This situation is called deadlock.

s vishnu murthy , M.Tech.,

(Ph.D)
 The Two-Phase Locking Protocol
• Two-phase locking does not ensure freedom from
deadlocks
• When two transactions are waiting for each other
for release of locks and neither of them proceeds
with normal execution, it is called DEADLOCK.
• Cascading roll-back is possible under two-phase
locking. To avoid this, follow a modified protocol
called strict two-phase locking. Here a
transaction must hold all its exclusive locks till it
commits successfully preventing any other
transaction from reading the data.

s vishnu murthy , M.Tech.,

(Ph.D)
 Time stamp based protocols

If the transactions T1,T2,T3 are executed

concurrently, the result must be same as serial
execution of the same transactions. Such concurrent
schedules are called serializable schedules.

So to make the effect of a concurrent schedule same

as a serial schedule, we can use the time stamps of
the transactions to avoid any conflicts between
transactions.
Because if the above transactions are performed
serially, the operations of T1 are first done then T2 ,
then T3.So to preserve that order ,in case of
concurrent execution, the time stamps of transactions
can be compared.
s vishnu murthy , M.Tech.,
(Ph.D)
 Timestamp-Based Protocols
• Each transaction is assigned a timestamp at start up. At
execution time we can ensure that if action ai of transaction Ti
conflicts with action aj of transaction Tj , ai occurs before aj if
TS(Ti) <TS(Tj).If an action violates this ordering ,the transaction
is aborted and restarted.
• Implementation
• Every database object O is given a read time stamp RTS(O) and
write time stamp WTS(O) .If transaction tries to read object O
and TS(T) < WTS(O) ,the order of this read with respect to the
most recent write on O would violate the time stamp order
between this transaction and the writer.There fore T is aborted
and restarted with a new larger time stamp.
• If TS(T) >WTS(O) T reads O and RTS(O) is set to the larger of
RTS(O) and TS(T).

s vishnu murthy , M.Tech.,

(Ph.D)
 Timestamp-Based Protocols

• When transaction T wants to write object O

• If TS(T) <RTS(O) the write action conflicts with the most
recent read action of O ,there fore T is aborted and
restarted.
• If TS(T) <WTS(O) it is an outdated write.T is aborted.
• Otherwise T writes O and WTS(O) is set to TS(T).

s vishnu murthy , M.Tech.,

(Ph.D)
 Validation-Based Protocol
• In a system with light contention with data objects , the
overhead of locking protocol is not advisable.
• In optimistic concurrency control, we assume that most
transactions do not conflict. So the transactions are
allowed to execute freely.
• They proceed in 3 phases
• read – the transaction executes reading values from the
database and writing to a private workspace.
• Validation- if the transaction decides that it wants to
commit, the DBMS checks whether it will conflict with any
other concurrent transaction .if so, it is aborted.private
workspace is cleared
• Write- if validation determines that there are no possible
conflicts ,the private work space is copied to the database.

s vishnu murthy , M.Tech.,

(Ph.D)
 Multiple granularity
Using this we can set locks on objects that contain
other objects
Example
Data base contains number of files.A file is a
collection of pages .A page is a collection of records
A transaction expects to access most pages of file,
should set lock on the entire file Rather than locking
individual pages.it reduces the locking overhead

If it requires only parts of a file and if it locks entire

file, the parts that are not needed are also locked
which blocks other transactions

s vishnu murthy , M.Tech.,

(Ph.D)
 Multiple Granularity

• Can be represented graphically as a tree

• When a transaction locks a node in the tree explicitly, it
implicitly locks all the node's descendents in the same mode.
• Granularity of locking
– fine granularity (lower in tree): high concurrency, high
locking overhead
– coarse granularity (higher in tree): low locking overhead,
low concurrency

s vishnu murthy , M.Tech.,

(Ph.D)
Example of Granularity Hierarchy

The levels, starting from the coarsest (top) level are

– database
– area
– file
– record
s vishnu murthy , M.Tech.,
(Ph.D)
 Intention Lock Modes

• In addition to S and X lock modes, there are three additional

lock modes with multiple granularity:
– intention-shared (IS): To lock a node in S mode, A
transaction must lock all it’s ancestors in IS mode.if a
transaction locks a node in S mode, no other transaction can
have locked any ancestor in X mode.IS locks conflict only
with X locks
– intention-exclusive (IX):To lock a node in X mode, A
transaction must lock all it’s ancestors in IX mode.if a
transaction locks a node in X mode, no other transaction
can have locked any ancestor in S or X mode.
– shared and intention-exclusive (SIX):if a transaction needs
to read an entire file and modifies a few of the records in it ,
so it needs an S lock on file and IX lock so that it can later
lock some of the objects in X mode.SIX lock combination of S
and IX locks.
s vishnu murthy , M.Tech.,
(Ph.D)
 Compatibility Matrix with
Intention Lock Modes

• The compatibility matrix for all lock modes is:

IS IX S S IX X
IS     

IX     

S     

S IX     

X     

s vishnu murthy , M.Tech.,

(Ph.D)
 Specialized locking techniques
Dynamic databases -which grow and shrink through insertion and
deletion of objects which is not a fixed collection of objects.With dynamic
databases we face a problem called phantom problem.
Dynamic databases and phantom problem:-
Even though strict 2PL is implemented , interleaved execution of set of
transactions may not be equal to any serial execution as the database
grows and shrinks dynamically.
Supp t1 scans sailors relation to find oldest sailors for rating 1 and 2
It may lock all the pages containing sailors with rating 1 and get the result
as 71.
Next, t2 may insert new sailors with rating 1 and age 96 on a page which
does not contain any sailors with rating 1.which was not locked by t1.so an
exclusive lock on this page will not conflict with any of the locks held by t1.
T2 also locks the page containing the oldest sailor with rating 2 and deletes
this sailor(age is say 80).T2 then commits and releases locks.T1 now
identifies and locks pages containing sailors

s vishnu murthy , M.Tech.,

(Ph.D)
With rating 2 and finds age of the oldest such sailor which is say 63.The
result of interleaved execution is 71 and 63.if t1 is executed first ,then
t2, we would get 71 and 80.if t2 had run first,then t1, we would get 96
and 63.so the result is not identical to any serial execution even though
they follow strict 2PL.
Solution”-
1)if there is no index and all pages must be scanned ,t1 must ensure
that new pages are not added to the file besides locking existing pages.
2.T1 can get lock on the index page if there exists.
Concurrency control in B+ trees
In a B+ tree , higher level nodes only direct searches and the real data
is in the leaf levels.
For searches , shared locks must be obtained on nodes starting at the
root and proceeding along a path to the desired leaf.a lock on a node
can be released a lock on the child node is obtained.
For inserts , a node must be locked in exclusive mode only if a split can
propogate upto it from the modified leaf.

s vishnu murthy , M.Tech.,

(Ph.D)
Ex. To search for a data entry 38 , a transaction T must obtain S lock on
node A ,read the contents and determine that it needs to examine node
B ,obtain an S lock on node B and release the lock on A ,obtain an S lock
on node C and release the lock on B and obtain S lock on D and release
lock on C.
Fig:-17.5 raghu rama krishnan

Multiple granularity locking:-

It allows locking objects that contain other objects.that is locking is allowed
at file level.page level, record level.
Here besides shared and exclusive locks ,Intension shared(IS) and
intension Exclusive(IX) are used.
IS locks conflicts only with X locks.
IX locks conflicts with S and X locks.
To lock a node in S mode, a transaction must lock all it’s ancestors in IS
mode. Thus if a transaction locks a node in S mode, no other transaction
can have locked any ancestor in X mode.similarly if a transaction locks a
node in X mode, no other transaction can have locked any ancestor in S or
X mode.
s vishnu murthy , M.Tech.,
(Ph.D)
This ensures that no other transaction holds a lock on an ancestor that
conflicts that conflicts with the requested S or X lock on the node.

Concurrency control without locking

1.Optimistic concurrency control:
Here we allow as many transactions possible to execute with a hope that
they do not conflict.
Transactions proceed in three phases:
Read:- the transaction executes ,reading values from the database and
writing to a private workspace.
Validation-when a transaction wants to commit,the dbms checks for any
conflicts with other transactions.if there is a possiblity of a conflict, the
transaction is aborted,it’s workspace is cleared and it is restarted.
Write:-if there are no possible conflicts, the changes made by the
transaction in the private workspace are copied onto the database.
Transactions assigned timestamps ,checks that the time stamp ordering of
a transaction is an equivalent serial
s vishnu order.
murthy , M.Tech.,
(Ph.D)
2.Time stamp based concurrency control:
Each transaction can be assigned a time stamp at start up and we can
ensure at execution time that if an action ai of transaction Ti conflicts with
action aj of Tj , ai occurs before aj if TS(ti)<TS(Tj).If an action violates this
ordering , the transaction is aborted and restarted.
Every object O is given a read time stamp RTS(O) and a write time stamp
WTS(O)., if a transaction T wants to read object O and TS(T) < WTS(O),
the order of this read with respect to the most recent write on O would
violate the timestamp order between this transaction and the writer.then T
aborted and restarted with a new larger time stamp.if TS(T) > WTS(O) ,T
reads O and RTS(O) is set to the larger of RTS(O) and TS(T).
Similarly when T wants to write an object.

3.Multiversion concurrency control.

The goal is that a transaction never has to wait to read a database object.
The idea here to maintain several versions of database objects ,each with a
write time stamp and let transaction Ti read the most recent version whose
time stamp precedes TS(Ti).if a transaction Ti wants to write an object ,
we must ensure that the object has not already been read by some other
s vishnu murthy , M.Tech.,
transaction Tj. Make sure that TS(Ti)<TS(Tj).
(Ph.D)
 Crash recovery-ARIES ALGORITHM

ARIES-is a recovery algorithm.Designed to work with steal and no

force approach.When a recovery manager is invoked after a
crash ,restart proceeds in 3 phases
1) Analsysis-identifies dirty pages in buffer and active transactions
2) Redo-repeats all actions starting from an appropriate point in the
log and restores the database state to what it was at the time of
crash
3) Undo-undoes the actions of transactions that did not commit.
The main principles of Aries algorithm
a) Write-ahead logging-any change to database is first recorded in the
log
b) Repeating history during Redo-on restart after crash,it retraces all
actions of DBMS before the crash brings the system to exact state
as before the crash.it undoes the actions of uncommited
transactions
c) Logging changes during Undo-changes
s vishnu made to Database while
murthy , M.Tech.,
undoing a transaction are also(Ph.D)
logged.
 THE LOG
Also called as TRIAL OR JOURNAL
Log is history of actions executed by the DBMS on stable storage
Most recent portion of log is called log tail.
Every log record has unique id called LSN(log sequence number)
For recovery purpose,every page in the database contains the LSN of
the most recent log record that describes a change to the page.
A log record is written each of these actions
1. Updating a page
2. Commit
3. Abort
4. End
5. Undoing an update
Every log record has the fields PrevLSN,transID,and type.
All records for a given transaction is maintained as linked list going back
s vishnu murthy , M.Tech.,
in time. List must be updated when
(Ph.D)
new log record is added.
 Other recovery related structures

In addition to the log ,the following two tables contain important recovery
related information.
Prev Tran- type Page- length offset Before After
LSN ID ID image image

T1000 Updat p500 3 21 ABC DEP

e

T2000 updat p600 3 41 HU KLM

e

T2000 updat p500 3 20 GDE QRS

e

T1000 updat p505 3 24 TUV WXY

e

s vishnu murthy , M.Tech.,

THE LOG
(Ph.D)
Transaction table:-it contains one entry for each active
transaction.
It contains the Transaction ID, lastLSN, the status.lasLSN is the
most recent log record for that transaction.status may be in
progress, committed or aborted.

Dirty page table:-it contains one entry for each dirty page in
the buffer pool. That is each page with changes not yet
reflected on disk.
It contains recLSN-LSN of the first log record that caused the
page to become dirty.it identifies the earliest log record that
might have to be redonefor this page during restart after a
crash.

s vishnu murthy , M.Tech.,

(Ph.D)
 THE WRITE AHEAD LOG PROTOCOL(WAL)

Before writing a page to disk ,every update log record must be

forced to stable storage.means forcing all log records upto and
including the one with LSN equal to the pageLSN to stable storage.
PageLSN-for recovery purpose every page in the database contains
the LSN of the most recent LOG record that describes a change to
the page.
WAL protocol ensures that a record of every change to the database
is available while attempting to recover from a crash.
A committed transaction means a transaction whose all of log
records including a commit record has been written to a stable
storage.

s vishnu murthy , M.Tech.,

(Ph.D)