Reliability, Transactions,

Concurrency
Reliability , Transactions & Concurrency
Reliable System: if it functions as per its
specifications and produces a correct set of out
values for a given set of input values.
Failure of system: if it does not functions as per the
specifications and fail to deliver the service for
which it was intended.
Error: when component of a system assumes
undesirable state.
Fault: when an error is propagated from one
component to another
 Reliability
Systems

Fault tolerant system Fault Avoidance system

Fault Tolerant system:

• Has redundant component and subsystems and during
failure these redundant system replaces the faulty
components.
• Measures of reliability are
– Mean time to failure
– Mean time to repair
– System availability
 Reliability
• Fault avoidance system
– Reliability is achieved by using reliable components
and careful assembling techniques with
comprehensive testing at each stage of design and
assembly to eliminate all sources of errors.
• Types of failure
– Hardware failure
• Design error
• Poor quality control
• Overutilization and overloading
• wearout
 Reliability
– Software failure
• Design error
• Poor quality control
• Overutilization and overloading
• Wearout
– Storage medium failure
• Volatile storage
– System crash
• Non-volatile
– Read-write head
 Errors in database systems
• User error
– Errors made by users in application programme.
– By giving full access to the database for online users
• Consistency errors
– Required consistency specifications leftout
• System error
– Due to deadlock
– Due to operating system
• External environment
– Failure of power supply etc.
 Transaction
• A transaction is a very small unit of a program
and it may contain several low level tasks.
• A transaction can be defined as a group of
tasks act as a single task with minimum
processing unit which cannot be divided
further.
 Transactions
• All types of database access operation which
are held between the beginning and end
transaction statements are considered as a
single logical transaction in DBMS.
• During the transaction the database is
inconsistent. Only once the database is
committed the state is changed from one
consistent state to another.
Transactions
 ACID Properties
• Atomicity
– This property states that a transaction must be
treated as an atomic unit, that is, either all of its
operations are executed or none.
– There must be no state in a database where a
transaction is left partially completed.
– States should be defined either before the
execution of the transaction or after the
execution/abortion/failure of the transaction.
 ACID Properties
• Consistency
– The database must remain in a consistent state
after any transaction.
– No transaction should have any adverse effect on
the data residing in the database.
– If the database was in a consistent state before
the execution of a transaction, it must remain
consistent after the execution of the transaction
as well.
 ACID Properties
• Isolation
– In a database system where more than one
transaction are being executed simultaneously
and in parallel, the property of isolation states that
all the transactions will be carried out and
executed as if it is the only transaction in the
system.
– No transaction will affect the existence of any
other transaction.
 ACID Properties
• Durability
– The database should be durable enough to hold all its
latest updates even if the system fails or restarts.
– If a transaction updates a chunk of data in a database
and commits, then the database will hold the modified
data.
– If a transaction commits but the system fails before
the data could be written on to the disk, then that
data will be updated once the system springs back into
action.
 States of transactions
State Transaction type
Active State A transaction enters into an active
state when the execution process
begins. During this state read or write
operations can be performed.
Partially Committed A transaction goes into the partially
committed state after the end of a
transaction.
Committed State When the transaction is committed to
state, it has already completed its
execution successfully. Moreover, all
of its changes are recorded to the
database permanently.
 States of Transactions
Failed State A transaction considers failed when
any one of the checks fails or if the
transaction is aborted while it is in the
active state.
Terminated State State of transaction reaches
terminated state when certain
transactions which are leaving the
system can't be restarted.
States of Transaction
 States of Transactions
• Once a transaction states execution, it becomes active. It can issue
READ or WRITE operation. this is an Initial State
• Once the READ and WRITE operations complete, the transactions
becomes partially committed state.
• Next, some recovery protocols need to ensure that a system
failure will not result in an inability to record changes in the
transaction permanently. If this check is a success, the transaction
commits and enters into the committed state.
• If the check is a fail, the transaction goes to the Failed state.
• If the transaction is aborted while it's in the active state, it goes to
the failed state. The transaction should be rolled back to undo the
effect of its write operations on the database.
• The terminated/Aborted state refers to the transaction leaving
the system.
 Serializability

When multiple transactions are being executed

by the operating system in a
multiprogramming environment, there are
possibilities that instructions of one
transactions are interleaved with some other
transaction.
 Serializability
1.The execution sequence of an instruction in a
transaction cannot be changed, but two
transactions can have their instructions
executed in a random fashion.
2.Execution allowed if two transactions are
mutually independent and working on
different segments of data; but in case these
two transactions are working on the same
data, then the results may vary.
 Contd.
Given an interleaved execution of set of n transactions ,
the following conditions hold for each transaction in a set.
• All transactions are correct in the sense that if
any one of the transactions is executed by itself
on a consistent database, the resulting database
will be consistent.
• any serial execution of transactions are also
correct and preserve the consistency of
database; the result obtained are correct
 Schedule

• A chronological execution sequence

of a transaction is called a
schedule.
• A schedule can have many
transactions in it, each comprising
of a number of instructions/tasks.
Types of schedules in DBMS
 Serial Schedule
• Serial Schedule
– A serial schedule is one in which no transaction
starts until a running transaction has ended are
called serial schedules.
– It is a schedule in which transactions are aligned in
such a way that one transaction is executed first
and then 2nd and so on.
– When the first transaction completes its cycle,
then the next transaction is executed.
 Non serial Schedule
Non-Serial Schedule:
This is a type of Scheduling where the operations of
multiple transactions are interleaved.
 Serializability

Serializability:

1) Conflict Serializability
2) View Serializability
Conflict Serializable

consider a schedule S in which there are two consecutive instructions I i and

Ij of transactions Ti and Tj where i≠ j. if Ii and Ij refers to different data
items, then we can swap the Ii and Ij but if they refer to same data item
then the order matters. following are four cases:

1. Ii =read (q), Ij =read (Q) means they refers to same data item and
order does not matter (permutable operation)
2. Ii =read (q), Ij =write (Q) if Ii comes before Ij then Ti does not read a
value that is going to be written by Tj but if Ij comes before Ii then Ti
can read the value that is written by Tj. (non-permutable operation)
3. Ii =write (q), Ij = read (Q) .(non-permutable operation)
4. Ii =write (q), Ij = write (Q) order does not matter (permutable
operation).

we can swap the non-conflicting instruction from Schedule S and

create a new schedule S’ and we say that S and S’ are conflict
equivalent
View serializable
Three conditions for View Serializability.
1. for each data item Q, If Ti reads the initial value of Q in
schedule S then transaction Ti must also read the initial
value of Q in S’ .
2. for each data item Q, If Ti executes reads(Q) in Schedule
S and if that value was produced by write (Q) by
transaction Tj, then read (Q) operation of transaction Ti
must, in schedule S’, also read the value of Q produced
by the same write (Q) operation of Tj.
3. for each data item Q, transaction that performs the final
write(Q) operation in schedule S must perform the final
write(Q)operation in schedule S’.
 Precedence Graph
Precedence Graph is used to test serializability
of a schedule
It is a directed Graph (V, E) consisting of a set of nodes V = {T 1,
T2, T3……….Tn} and a set of directed edges E = {e1, e2,
e3………………em}. the set of V consists of all transactions in
schedule and set of edges consists of all edges Ti -> Tj for which
one of the condition holds.
1. Ti executes write (Q) before Tj executes read (Q) : write
before read
2. Ti executes read (Q) before Tj executes write (Q) : read
before write
3. Ti executes write(Q) before Tj executes write (Q) : write
before write
 Precedence Graph Example
S : r1(x) r1(y) w2(x) w1(x) r2(y)
 Precedence Graph Example
S1: r1(x) r3(y) w1(x) w2(y) r3(x) w2(x)
 precedence graph
If graph contains cycles then the schedule is
not Conflict serializable otherwise it is conflict
serializable
 Type of Non-Serializable
Non-Serializable:
The non-serializable schedule is divided into two
types,

1. Recoverable
2. Non-recoverable Schedule.
 Properties of schedule
• Recoverable:
– a schedule where, if transaction Tj reads a change made by
transaction Ti, Ti commits before Tj.
• Cascadeless:
– a schedule where, if transaction Tj reads a change made by
transaction Ti, Ti commits before read operation of Tj.
– means where every transaction can only read changes of committed
transactions
• Strict:
– a schedule where every transaction does not read or write values changed by
any other active transaction
 Concurrency
The Transaction Manager should guarantee that
concurrently executing transactions do not
interfere with each other. If this is not the
case, 4 basic types of problems could arise:
– Lost Update: concurrent updates
– Dirty Read: reading uncommitted data
– Unrepeatable Read: interleaving reads and
Writes
– Phantom Row: new data not appearing in the
result of a query
 Examples of isolation problem
• Lost Update: two people, in different shops, buy the
very last ticket for the A Movie (!?)
• Dirty Read: Some tour schedule shows a date e.g
15/07/17, but when you try to buy the ticket for that
tour, the system tells that no such date exists (!?)
• Unrepeatable Read: dates of 1st show for some movie
the date has been decided, you see a price of Rs.
10,000 , you think about it a little, but when you’re
decided, the price is risen to Rs. 15000 (!?)
• Phantom Row: you want to go see both shows of
some concert , but when you try to buy tickets, you
discover that there are now three dates (!?)
 Lost Update
• The following schedules show a typical lost
update case, where we also highlight
operations updating the value of X and show
how the value of X in the DB varies over
timeThe problem arises because T2reads the
value of Xbefore T1(that already read it)
updates it (“both transactions see the last
ticket”)
 Lost Update
• The problem arises because T2reads the
value of X before T1(that already read it)
updates it (“both transactions see the last
ticket”)
 Dirty Read
• In this case, the problem arises because a
transactions read a value that is not correct:
 Dirty Read
• What T2 does is based on an “intermediate”,
non-stable value of X, Consequences are
unpredictable (it depends on what T2 does)
and would be present even if T1 would not
abort
 Unrepeatable Read
• Now the problem is that a transaction reads a
value twice, with different
outcomes(“meanwhile, the price has
increased”)
 Phantom Row
• This case could arise only when tuples are
deleted or inserted that should be logically
considered by another transaction E.g.:
record r4 is “phantom”, since T1 “dose not
see it”
Thanks