UNIT -3

TRANSACTIONS
TRANSACTION CONCEPTS
 Collections of operations (processes) that form
a single logical unit of work are called
transactions.
 A transaction includes one or more database
access operations. These can include insertion,
deletion, modification or retrieval operations.
 These operations executed between the begin
transaction and end transaction.
 read(X), which transfers the data item X from
the database to a local buffer belonging to the
transaction that executed the read operation.
 write(X), which transfers the data item X from the local
buffer of the transaction that executed the write back
to the database.
 Let's take an example to debit transaction from
an account which consists of following
operations:
R(X);
X = X - 500;
W(X);
  Let's assume the value of X before starting of the transaction
is 4000.
 The first operation reads X's value from database and stores it
in a buffer.
 The second operation will decrease the value of X by 500. So
buffer will contain 3500.
 The third operation will write the buffer's value to the
database. So X's final value will be 3500.
 But it may be possible that because of the failure of
hardware, software or power, etc. that transaction may fail
before finished all the operations in the set.
 For example: If in the above transaction, the debit transaction
fails after executing operation 2 then X's value will remain
4000 in the database which is not acceptable by the bank.
 To solve this problem, we have two important operations:
 Commit: It is used to save the work done permanently.
 Rollback: It is used to undo the work done.
TRANSACTION PROPERTY
 The transaction has the four properties. These
are used to maintain consistency in a
database, before and after the transaction.
 Property of Transaction
 Atomicity

 Consistency

 Isolation

 Durability
ATOMICITY
 All operations of the transaction take place at
once if not, the transaction is aborted.
 Each transaction is treated as one unit and
either run to completion or is not executed at
all.
 Atomicity involves the following two operations:

 Abort: If a transaction aborts then all the

changes made are not visible.
 Commit: If a transaction commits then all the

changes made are visible.

 Example: Let's assume that following transaction T consisting
of T1 and T2. A consists of Rs 600 and B consists of Rs 300.
Transfer Rs 100 from account A to account B.

 After completion of the transaction, A consists of Rs

500 and B consists of Rs 400.
 If the transaction T fails after the completion of
transaction T1 but before completion of transaction
T2, then the amount will be deducted from A but
not added to B. This shows the inconsistent
database state. In order to ensure correctness of
database state, the transaction must be executed
in entirety.
CONSISTENCY:
 No other transaction should run concurrently when
there is a transaction already running.
 For example:
 Account A is having a balance of 400$ and it is
transferring 100$ to account B & C both.
 So we have two transactions here.
 Let’s say these transactions run concurrently and
both the transactions read 400$ balance, in that
case the final balance of A would be 300$ instead
of 200$.
 This is wrong. If the transaction were to run in
isolation then the second transaction would have
read the correct balance 300$ (before debiting
100$) once the first transaction went successful.
ISOLATION
 The data which is used at the time of execution
of a transaction cannot be used by the second
transaction until the first one is completed.
 If the transaction T1 is being executed and
using the data item X, then that data item can't
be accessed by any other transaction T2 until
the transaction T1 ends.
DURABILITY:
 After a transaction completes successfully, the
changes made to the database persists, even if there
are system failures.
TRANSACTIONS STATES

 Active state
 The transaction is being executed.
 For example: Insertion or deletion or updating a
record is done here. But all the records are still not
saved to the database.
 Partially committed
 A transaction executes its final operation, but the data
is still not saved to the database.
 In the total mark calculation example, a final display of
the total marks step is executed in this state.
 Committed
 A transaction is said to be in a committed state if it
executes all its operations successfully. In this state, all
the effects are now permanently saved on the database
system.
 Failed state
 If any of the checks made by the database recovery
system fails, then the transaction is said to be in the
failed state.
 In the example of total mark calculation, if the database
is not able to fire a query to fetch the marks, then the
transaction will fail to execute.
ABORTED
 If the transaction fails in the middle of the
transaction then before executing the
transaction, all the executed transactions are
rolled back to its consistent state.
 After aborting the transaction, the database
recovery module will select one of the two
operations:
 Re-start the transaction
 Kill the transaction
SCHEDULE
 A series of operation from one transaction to
another transaction is known as schedule.
SERIAL SCHEDULE
 The serial schedule is a type of schedule where
one transaction is executed completely before
starting another transaction.
NON-SERIAL SCHEDULE
 If interleaving of operations is allowed, then
there will be non-serial schedule.
 It contains many possible orders in which the
system can execute the individual operations of
the transactions.
SERIALIZABILITY
 Serializability is a concurrency scheme where
the concurrent transaction is equivalent to one
that executes the transactions serially.
Types of Serializability
 Conflict
Serializability
 View Serializability
Conflict Serializability
 Conflict serializability defines two instructions of
two different transactions accessing the same
data item to perform a read/write operation.
 It deals with detecting the instructions that are
conflicting in any way and specifying the order
in which the instructions should execute in case
there is any conflict.
 A conflict serializability arises when one of the
instruction is a write operation.
The following rules are important in Conflict
Serializability

1. If two transactions are both read operation,

then they are not in conflict.

2. If one transaction wants to perform a read

operation and other transaction wants to perform
a write operation, then they are in conflict and
cannot be swapped.

3. If both the transactions are for write operation,

then they are in conflict, but can be allowed to
take place in any order, because the transactions
do not read the value updated by each other.
 Example
T1 T2
read(x)
write(x)
read(x)
write(x)
read(y)
write(y)
read(y)
write(y)
 Consider the previous schedule swap the non conflicting
instructions of previous schedule. (i.e., S1)
 Swap the read (y) instruction of T1 with the read (x) instruction of
T2.
 Swap the write (y) instruction of T1 with the write (x) instruction of
T2.
 Swap the write (y) instruction of T1 with the read (x) instruction of
T2.
 T1 T2
read(x)
write(x)
read(y)
write(y)
read(x)
write(x)
read(y)
write(y)
VIEW SERIALIZABILITY
 It can be derived by creating another schedule
out of an existing schedule and involves the
same set of transactions.
 Example : Let us assume two transactions T1
and T2 that are being serialized to create two
different schedules SH1 and SH2, where T1
and T2 want to access the same data item. Now
there can be three scenarios
CONCURRENCY
Concurrency control is the procedure in DBMS
for managing simultaneous operations without
conflicting with each another.
 In concurrency transaction, it faces Three
Concurrency Problems:
 The lost update problem
 The uncommitted dependency problem (or)
temporary update problem
 The inconsistent analysis problem (or) incorrect
summary problem
Lost update problem
 When two transactions that access the same
database items contain their operations in a
way that makes the value of some database
item incorrect, then the lost update problem
occurs.
 If two transactions T1 and T2 read a record and
then update it, then the effect of updating of
the first record will be overwritten by the
second update.
 At time t2, transaction-X reads A's value.
 At time t3, Transaction-Y reads A's value.
 At time t4, Transactions-X writes A's value on the basis of the
value seen at time t2.
 At time t5, Transactions-Y writes A's value on the basis of the
value seen at time t3.
 So at time T5, the update of Transaction-X is lost because
Transaction y overwrites it without looking at its current
value.
 Such type of problem is known as Lost Update Problem as
update made by one transaction is lost here.
INCONSISTENT RETRIEVALS PROBLEM
 When a transaction calculates some summary
function over a set of data while the other
transactions are updating the data, then the
Inconsistent Retrievals Problem occurs.
 Transaction-X is doing the sum of all balance
while transaction-Y is transferring an amount
50 from Account-3 to Account-1.
 Transaction-X is doing the sum of all balance
while transaction-Y is transferring an amount 50
from Account-1 to Account-3.
 Here, transaction-X produces the result of 550
which is incorrect.
 If we write this produced result in the database,
the database will become an inconsistent state
because the actual sum is 600.
 Here, transaction-X has seen an inconsistent
state of the database.
CONCURRENCY CONTROL PROTOCOL
 The concurrency control protocol can be
divided into three categories:
 Lock based protocol
 Time-stamp protocol

 Validation based protocol

LOCK-BASED PROTOCOL
 Any transaction cannot read or write data until
it acquires an appropriate lock on it.
There are two types of lock:
1. Shared lock:
 It is also known as a Read-only lock

 In a shared lock, the data item can only read by

the transaction.
 It can be shared between the transactions
because when the transaction holds a lock, then
it can't update the data on the data item.
2. Exclusive lock:
 In the exclusive lock, the data item can be both
reads as well as written by the transaction.
 This lock is exclusive, and in this lock, multiple
transactions do not modify the same data
simultaneously.
FOUR TYPES OF LOCK PROTOCOLS

1. Simplistic lock protocol

All the transactions to get the lock on the
data before insert or delete or update on it.
It will unlock the data item after completing
the transaction
2. Pre-claiming Lock Protocol
 Pre-claiming Lock Protocols evaluate the transaction
to list all the data items on which they need locks.
 If all the locks are granted then this protocol allows
the transaction to begin. When the transaction is
completed then it releases all the lock.
 If all the locks are not granted then this protocol
allows the transaction to rolls back and waits until all
the locks are granted.
TWO-PHASE LOCKING (2PL)
 The two-phase locking protocol divides the
execution phase of the transaction into three parts.
 In the first part, when the execution of the
transaction starts, it seeks permission for the lock
it requires.
 In the second part, the transaction acquires all the
locks. The third phase is started as soon as the
transaction releases its first lock.
 In the third phase, the transaction cannot demand
any new locks. It only releases the acquired locks.
 There are two phases of 2PL:
 Growing phase: In the growing phase, a new lock
on the data item may be acquired by the
transaction, but none can be released.
 Shrinking phase: In the shrinking phase, existing
lock held by the transaction may be released, but
no new locks can be acquired.
STRICT TWO-PHASE LOCKING (STRICT-2PL)
 Once it receives the lock on the data, it
completes the transaction.
 Here it does not release the locks as it is used
and no more required.
 It waits till whole transaction to complete and
commit, then it releases all the locks at a time.
 This protocol hence does not have shrinking
phase of lock release.
RIGOROUS 2 PHASE LOCKING
 All the locks on transactions are kept till the
transaction is committed or aborted.
 This more strict protocol than others above.

 The transactions can be serialized by the order

they are committed.
TIMESTAMP-BASED PROTOCOLS
 This protocol uses either system time or logical
counter as a timestamp.
 Lock-based protocols help you to manage the
order between the conflicting transactions
when they will execute.
 Timestamp-based protocols manage conflicts
as soon as an operation is created.
Timestamp Ordering Protocol
 The conflicting pair of tasks should be executed according to the
timestamp values of the transactions.
 The timestamp of transaction Ti is denoted as TS(Ti).
 Read time-stamp of data-item X is denoted by R-timestamp(X).
 Write time-stamp of data-item X is denoted by W-timestamp(X).
Timestamp ordering protocol works as follows −
 If a transaction Ti issues a read(X) operation −
 If TS(Ti) < W-timestamp(X)
 Operation rejected.
 If TS(Ti) >= W-timestamp(X)
 Operation executed.
 All data-item timestamps updated.
 If a transaction Ti issues a write(X) operation −
 If TS(Ti) < R-timestamp(X)
 Operation rejected.
 If TS(Ti) < W-timestamp(X)
 Operation rejected and Ti rolled back.
 Otherwise, operation executed.
DEADLOCK IN DBMS

 A deadlock is an unwanted situation in which

two or more transactions are waiting
indefinitely for one another to give up locks.
 For example: In the student table, transaction
T1 holds a lock on some rows and needs to
update some rows in the grade table.
 Simultaneously, transaction T2 holds locks on
some rows in the grade table and needs to
update the rows in the Student table held by
Transaction T1.
DEADLOCK AVOIDANCE
 Deadlock avoidance mechanism is used to
detect any deadlock situation in advance.
 A method like "wait for graph" is used for
detecting the deadlock situation but this
method is suitable only for the smaller
database.
 For the larger database, deadlock prevention
method can be used.
 Serializable
schedule

View Conflict
Serializability Serializability