Advance Database

Chapter 3
Transaction Processing Concepts
A transaction is a sequence of operations performed (using one or more SQL
Introduction to Transactions

statements) on a database as a single logical unit of work. The effects of all the

SQL statements in a transaction can be either all committed (applied to the

database) or all rolled back (undone from the database).

 A transaction is the propagation of one or more changes to the database. For
example, if you are creating a record or updating a record or deleting a record
Transaction and system concepts

from the table, then you are performing a transaction on that table. It is
important to control these transactions to ensure the data integrity and to
handle database errors.

Practically, you will club many SQL queries into a group and you will execute
all of them together as a part of a transaction.
 A transaction could be a whole program, part/module of a program or a
single command. Transaction and system concepts

 Changes made in real time to a database are called transactions. Examples

include ATM transactions, credit card approvals, flight reservations, hotel
check-in, phone calls, supermarket canning, academic registration and
billing.
The following are the three main types of transactions:

•Retrieval transactions: Retrieves data from the database to be displayed on the

Transactions Types

screen.
 

•Update transactions: Inserts new records, deletes old records, or modifies

existing records in the database.

•Mixed transactions: Involves both the retrieval and updating of data.

 Inthe absence of failures, all transactions complete successfully. However, a
transaction may not always complete its execution successfully. Such a
transaction is termed aborted.
Transactions State

 A transaction that completes its execution successfully is said to be committed.

 

The following figure shows that if a transaction has been partially committed
then it will be committed but only if it has not failed and if the transaction has
failed, it will be aborted.
 

 
Transactions State
Properties of Transactions
 

Transactions have the following four standard properties, usually referred

to by the acronym ACID.

Atomicity − ensures that all operations within the work unit are
completed successfully. Otherwise, the transaction is aborted at the point
of failure and all the previous operations are rolled back to their former
state. Every transaction should be considered as an atomic process which
can not be sub divided into small tasks.
Properties of Transactions
 

Transactions have the following four standard properties, usually referred to

by the acronym ACID.

Consistency − ensures that the database properly changes states upon a

successfully committed transaction. If the transaction code is correct then
a transaction, at the end of its execution, must leave the database
consistent. A transaction should transform a database from one previous
consistent state to another consistent state. At the end of the transaction,
all data must be left in a consistent state.
 Properties of Transactions
Isolation − enables transactions to operate independently of and
transparent to each other. Modifications of data performed by a transaction
must be independent of another transaction. Unless this happens, the
outcome of a transaction may be erroneous. A transaction must execute
without interference from other concurrent transactions and its intermediate
or partial modifications to data must not be visible to other transactions.
Properties of Transactions
Durability − ensures that the result or effect of a committed transaction
persists in case of a system failure. When the transaction is completed,
effects of the modifications performed by the transaction must be permanent
in the system.

 Often these four properties of a transaction are acronymed as ACID.

 Simple example of transaction
Example of Fund Transfer
Transaction to transfer $1000 from account X to account Y:
1.read(X)
2.X = X –1000
3.write(X)
4.read(Y)
5.Y = Y + 1000
6.write(Y)
 Cont.…
•Atomicity requirement — if the transaction fails after step 3 and before
step 6, the system should ensure that its updates are not reflected in the
database, else an inconsistency will result.

•Consistency requirement –If between steps 3 and 6, another transaction

is allowed to access the partially updated database, it will see an
inconsistent database.
 Cont.…
•Isolation can be ensured by running transactions serially, that is one after
the other.
• However, executing multiple transactions concurrently has
significant benefits.

•Durability requirement — once the user has been notified that the
transaction has completed (i.e., the transfer of the $1000 has taken place),
the updates to the database by the transaction must persist.
 Schedules in DBMS
•A schedule is the order in which the operations of multiple transactions
appear for execution.
Types of Schedules in DBMS
1. Serial Schedule
In Serial schedule, a transaction does not start execution until the currently
running transaction finished execution. Transactions are executed step by step
orderly.
2. Non-serial schedule
This is a type of Scheduling where the operations of multiple transactions are
interleaved. It can be of two types namely, Serializable and Non-Serializable
Schedule.
Type of Serial Schedule
 Type of Non-Serial Schedules
vv
 Serializable Schedule
What is a serializable schedule?
Serializability: is a concept that helps to identify which non-serial
schedules are correct and will maintain the consistency of the database.
A serial schedule is always a serializable schedule because in serial
schedule, a transaction only starts when the other transaction finished
execution. However a non-serial schedule needs to be checked for
Serializability.
A serializable schedule helps in improving both resource utilization and
CPU throughput. These are of two types:
 Serializability in DBMS
Serial Schedules Serializable Schedules

No concurrency is allowed. Concurrency is allowed.

Thus, all the transactions necessarily Thus, multiple transactions can execute
execute serially one after the other. concurrently.

Serializable schedules improve both

Serial schedules lead to less resource
resource utilization and CPU
utilization and CPU throughput.
throughput.

Serial Schedules are less efficient as Serializable Schedules are always better
compared to serializable schedules. than serial schedules.
(due to above reason) (due to above reason)
 Type of Serializable Schedule
1.Conflict Serializable:
A schedule is called conflict serializable if it can be transformed into a serial
schedule by swapping non-conflicting operations. Two operations are said to
be conflicting if all conditions satisfy:
1.They belong to different transactions
2.They operate on the same data item
3.At Least one of them is a write operation
2.View Serializable:
A Schedule is called view serializable if it is view equal to a serial schedule
(no overlapping transactions).
 Type of Serializable Schedule
1.Conflict Serializable:
Example: Consider the following Schedule S (Non-Serial Schedule):
Time Transaction T1 Transaction T2 Transaction T3

t1 Read(X)    
t2     Read(Y)
t3     Read(X)
t4   Read(Y)  
t5   Read(Z)  
t6     Write(Y)
t7   Write(Z)  
t8 Read(Z)    
t9 Write(X)    
t10 Write(Z)  
 Type of Serializable Schedule
1.Conflict Serializable:
Example: Consider the following Schedule S (Non-Serial Schedule):
Draw precedence graph:

To draw the edges between these nodes or vertices, follow the below steps:
Step1: At time t1, there is no conflicting operation for read(X) of Transaction T1.
Step2: At time t2, there is no conflicting operation for read(Y) of Transaction T3.
Step3: At time t3, there exists a conflicting operation Write(X) in transaction T1
for read(X) of Transaction T3. So, draw an edge from T3?T1.
 Type of Serializable Schedule
1.Conflict Serializable:
Example: consider the following Schedule S (Non-Serial Schedule):
Draw precedence graph:

Step4: At time t4, there exists a conflicting operation Write(Y) in transaction T3 for read(Y) of

Transaction T2. So, draw an edge from T2?T3.
Step5: At time t5, there exists a conflicting operation Write (Z) in transaction T1 for read (Z) of
Transaction T2. So, draw an edge from T2?T1.
 Type of Serializable Schedule
1.Conflict Serializable:
Example: consider the following Schedule S (Non-Serial Schedule):
Draw precedence graph:

Step6: At time t6, there is no conflicting operation for Write(Y) of Transaction T3.

Step7: At time t7, there exists a conflicting operation Write (Z) in transaction T1 for Write
(Z) of Transaction T2. So, draw an edge from T2?T1, but it is already drawn.
After all the steps, the precedence graph will be ready, and it does not contain any cycle or loop,
so the above schedule S is conflict serializable. And it is equivalent to a serial schedule. Above
schedule S is transformed into the serial schedule by using the following steps:
 Type of Serializable Schedule
1.Conflict Serializable: to check the order of schedule (serial order)
Step1: Check the vertex in the precedence graph where indegree=0. So, take the vertex T2
from the graph and remove it from the graph.

Step 2: Again check the vertex in the left precedence graph where indegree=0. So, take the
vertex T3 from the graph and remove it from the graph. And draw the edge from T2?T3.
 Type of Serializable Schedule
1.Conflict Serializable: to check whether it is conflict serializable.
Step3: And at last, take the vertex T1 and connect with T3.
 Type of Serializable Schedule
1.Conflict Serializable:
Example: consider the following Schedule S (Serial Schedule):
Time Transaction T1 Transaction T2 Transaction T3
t1   Read(Y)  
t2   Read(Z)  
t3   Write(Z)  
t4     Read(Y)
t5     Read(X)
t6     Write(Y)
t7 Read(X)    
t8 Read(Z)    
t9 Write(X)    
t10 Write(Z)    
 Type of Serializable Schedule
2. View Serializable:
Two schedules S1 and S2 are said to be view equivalent if both satisfy the following
conditions:
1. Initial read
An initial read of the data item in both the schedule must be same. For example, lets two schedule S1 and
S2. If transaction T1 reads the data item X in schedule S1, then in schedule S2 transaction T1 also reads
X.

Schedule 1: S1 Schedule 2: S2
Transaction Transaction Transaction Transaction
Time Time T1 T2
T1 T2
t1 Read(X)   t1   Write(X)
t2   Write(X) t2 Read(X)  

Above two schedules, S1 and S2 are view equivalent, because initial read instruction in S1 is done by T1
transaction and in schedule S2 is also done by transaction T1.
 Type of Serializable Schedule
2. View Serializable:
Two schedules S1 and S2 are said to be view equivalent if both satisfy the following conditions:
2. Updated Read
In schedule S1, if the transaction T i is reading the data item X which is updated by transaction T j,
then in schedule S2 also, Ti should read data item X which is updated by T j.
Schedule 2: S2
Schedule 1: S1

Transaction Transaction Transaction Transaction

Time Time
T1 T2 T1 T2

 t1 Write(X)    t1 Write(X)  

t2   Read(X) t2   Read(X)

Above two schedules S1 and S2 are view equivalent because in schedule S1 transaction T2 reads the data
item X which is updated by T1 and in schedule S2 T2 also reads the data item X which is updated by T1.  
 Type of Serializable Schedule
2. View Serializable:
Two schedules S1 and S2 are said to be view equivalent if both satisfy the following conditions:
3.Final write
 The final write operation on each data item in both the schedule must be same. In a schedule S1, if a transaction
T1 updates data item X at last then in schedule S2, final writes operations should also be done by T1 transaction.
Schedule 2: S2
Schedule 1: S1

Transaction Transaction Transaction

Time Time Transaction T1 Transaction T2 Transaction T3
T1 T2 T3
t1     Write(X)
t1     Write(X)
t2   Read(X)  
t3 Write(X)     t2   Read(X)  
t3 Write(X)    

Above two schedules, S1 and S2 are view equivalent because final write operation in schedule S1 is done
by T1 and in S2, T1 also does the final write operation.
 Type of Non-Serializable Schedules
The non-serializable schedule is divided into two types, Recoverable and
Non-recoverable Schedule.
Recoverable Schedule:
Schedules in which transactions commit only after all transactions whose
changes they read commit are called recoverable schedules. In other words,
if some transaction Tk is reading value updated or written by some other
transaction Ti, then the commit of Tk must occur after the commit of Ti.

A schedule is recoverable if
:each transaction commits only after all transactions from which it
has read has committed.
 Type of Recoverable Schedule:
1. Cascading Schedule: When there is a failure in one transaction and this
leads to the rolling back or aborting other dependent transactions, then such
scheduling is referred to as Cascading rollback or cascading abort.
 Type of Recoverable Schedule:
Cascadeless Schedule:
Schedules in which transactions read values only after all transactions whose
changes they are going to read commit are called cascadeless schedules.
If in a schedule, a transaction is not allowed to read a data item until the last
transaction that has written it is committed or aborted, then such a schedule is
called as a Cascadeless Schedule.
 Type of Recoverable Schedule:
Strict Schedule:
A schedule in which a transaction can neither read or write an item X until the
last transaction that wrote X has committed.
 Non Recoverable Schedule:
Read about those concepts:
Schedules in DBMS
 Testing of Serializability
To test the serializability of a schedule, we can use the serialization graph.
Suppose, a schedule S. For schedule S, construct a graph called as a
precedence graph. It has a pair G = (V, E), where E consists of a set of edges,
and V consists of a set of vertices. The set of vertices contain all the
transactions participating in the S schedule. The set of edges contains all edges
Ti ->Tj for which one of the following three conditions satisfy:
1.Create a node Ti ? Tj if Ti transaction executes write (Q) before Tj
transaction executes read (Q).
2.Create a node Ti ? Tj if Ti transaction executes read (Q) before Tj transaction
executes write (Q).
3.Create a node Ti ? Tj if Ti transaction executes write (Q) before Tj
transaction executes write (Q).
Transaction Support in SQL
 The following three T-SQL statements control transactions in SQL Server:
•BEGIN TRANSACTION: This marks the beginning of a transaction.
•COMMIT TRANSACTION: This marks the successful end of a transaction. It signals the
database to save the work.
•ROLLBACK TRANSACTION: This denotes that a transaction hasn't been successful and
signals the database to roll back to the state it was in prior to the transaction.
 
 Cont…
Transaction Control
The following commands are used to control transactions.
•COMMIT − to save the changes.
•ROLLBACK − to roll back the changes.
•SAVEPOINT − creates points within the groups of transactions in which to
ROLLBACK.
Transactional Control Commands
Transactional control commands are only used with the DML
Commands such as - INSERT, UPDATE and DELETE only. They cannot
be used while creating tables or dropping them because these operations
are automatically committed in the database.
The COMMIT Command
The COMMIT command used to save changes invoked by a transaction to
the database. The syntax for the COMMIT command is as follows.

Begin tran tran_Name

Command for operation
commit tran tran_Name
The COMMIT Command

Example

create table emp(empid int constraint PRIMARYKEY primary key, empName varch
ar(15)). Insert at least 5 data to this table and try the following operations.
1.begin tran d  
2.update emp set empName ='D' where empid=11  
3.commit tran d  

Here d is the name of the transactions and we update empName d to D in the table emp
on the basis of empId. The change made by this command will be permanent and we
could not Rollback after the commit command.
The ROLLBACK Command
The ROLLBACK command used to undo transactions that have not already
been saved to the database. This command can only be used to undo
transactions since the last COMMIT or ROLLBACK command was issued.

The syntax for a ROLLBACK command is as follows −

 begin tran tranName

Command for operation
Rollback tran tranName
The ROLLBACK Command
Example: We want that, if data entered by user has an empId less than 10 then the command is rolled back
and a message is shown to the user "An id less than 10 is not valid; query is rolled back".
1.begin tran t  
2.declare @id int;  
3.set @id=1;  
4.insert into emp values(@id,'d')  
5.if(@id<10)  
6.begin  
7.print'An id less than 10 is not valid; query is rolled back';  
8.rollback tran t;  
9.end   
10.else  
11.begin  
12.print 'data is inserted'  
13.end  
The SAVEPOINT Command

A SAVEPOINT is a point in a transaction when you can roll the transaction back
to a certain point without rolling back the entire transaction.

The syntax for a SAVEPOINT command is as shown below.

 SAVEPOINT SAVEPOINT_NAME
This command serves only in the creation of a SAVEPOINT among all the
transactional statements. The ROLLBACK command is used to undo a group of
transactions.
The syntax for rolling back to a SAVEPOINT is as shown below.

ROLLBACK TO SAVEPOINT_NAME
The RELEASE SAVEPOINT Command
The RELEASE SAVEPOINT command is used to remove a SAVEPOINT that you have
Types of Triggers

created.
The syntax for a RELEASE SAVEPOINT command is as follows

  RELEASE SAVEPOINT SAVEPOINT_NAME

Once a SAVEPOINT has been released, you can no longer use the ROLLBACK command
to undo transactions performed since the last SAVEPOINT.
Examples of commit, rollback and save point command
Types of Triggers
Con’t….
Types of Triggers
First create the following table and storeExercise
in database name DatabaseTransaction. Then
Q1. Write SQl Query that deletes those records with age values 20 and commit the
transaction after deletion and call the transaction name as CommitDeleteRecord.
 Cont..
Q2. Write SQl Query that deletes those records with age values 20 and
Rollback the transaction after deletion and call the transaction name as
RollbackDeleteRecord
 Cont…
Q3. Write SQl Query that deletes those records with age values 20 and also add one
record or row to the table and then ROLLBACK the changes in the database by keeping
Savepoints after deletion and call the transaction name as
RollbackSavePointDeleteRecord
Hint:
SAVEPOINT SP1;
//Savepoint created.
DELETE FROM Student WHERE AGE = 20;
//deleted
SAVEPOINT SP2;
//Savepoint created.
 Cont…
Here SP1 is first SAVEPOINT created before deletion. In this example one deletion
have taken place. 
After deletion again SAVEPOINT SP2 is created. 
Output: 
 
 Cont
Deletion have been taken place, let us assume that you have changed your mind and
decided to ROLLBACK to the SAVEPOINT that you identified as SP1 which is
before deletion. 
deletion is undone by this statement , 
ROLLBACK TO SP1; //Rollback completed.
 Cont..
Q4. Write SQl Query that rolled back the operation when the value for the
age entered less than 15 and a message is shown to the user “age less than
15 is not valid; query is rolled back". Otherwise, commit the operation.
Thank you……………….