Database Management Systems (DBMS)

GTU # 3130703

Chapter 3
Transaction Processing
P Outline
Looping
• What is transaction?
• ACID properties of transaction
• Transaction State Diagram \ State Transition
Diagram
• Schedule
• Two phase commit protocol
• Database recovery
• Concurrency
• Deadlock
Section – 1
What is transaction?
} A transaction is a sequence of operations performed as a single logical unit of
work.
} A transaction is a logical unit of work that contains one or more SQL statements.
} Example of transaction: Want to transfer ETB. 50 from Account-A to Account-B
Works as a
single logical
unit
read (A)
A = A – 50
Transactio
n write (A) Operations
read (B)
B = B + 50
write (B)
Section – 2
ACID properties of transaction
} Atomicity (Either transaction execute 0% or 100%)
} Consistency (Database must remain in a consistent state after any transaction)
} Isolation (Intermediate transaction results must be hidden from other concurrently
executed transactions)
} Durability (Once a transaction completed successfully, the changes it has made into
the database should be permanent)
ACID properties of transaction (Atomicity)
} This property states that a transaction must be treated as
an atomic unit, that is, either all of its operations are
0%
executed or none.
} Either transaction execute 0% or 100%. read (A)
} For example, consider a transaction to transfer Rs. 50 A = A – 50
from account A to account B. write (A)
FAI
} In this transaction, if Rs. 50 is deducted from account A read (B) L
then it must be added to account B. B = B + 50
write (B)
100%
ACID properties of transaction (Consistency)
} The database must remain in a consistent state after any A=500, B=500
transaction. A+B=1000
} If the database was in a consistent state before the
execution of a transaction, it must remain consistent after read (A)
the execution of the transaction as well. A = A – 50
} In our example, total of A and B must remain same before write (A)
and after the execution of transaction. read (B)
B = B + 50
write (B)
A=450, B=550
A+B=1000
ACID properties of transaction (Isolation)
} Changes occurring in a particular transaction will not be Start
Transaction
visible to any other transaction until it has been
committed. read (A)
} Intermediate transaction results must be hidden from A = A – 50
other concurrently executed transactions.
write (A)
} In our example once our transaction starts from first step read (B)
(step 1) its result should not be access by any other
transaction until last step (step 6) is completed. B = B + 50
write (B)
ACID properties of transaction (Durability)
} After a transaction completes successfully, the changes it A=500, B=500
has made to the database persist (permanent), even if
there are system failures. read (A)
} Once our transaction completed up to last step (step 6) its A = A – 50
result must be stored permanently. It should not be write (A)
removed if system fails.
read (B)
B = B + 50
write (B)
A=450, B=550
These values must be
stored permanently in the
database
Section – 3
Transaction Type
} The following are the three main types of transactions:

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

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.

Transaction State
} In the absence of failures, all transactions complete successfully. However, a
transaction may not always complete its execution successfully. Such a transaction
is termed aborted.
} 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.
Transaction State Diagram \ State Transition Diagram
The
Whentransaction enters
a transaction in this its
executes state after
final successful
operation, it is
completion
said to be inofa the transaction.
partially committed state. Aborted
Active
We cannot abort or rollback a committed transaction. read (A)
Partial A = A – 50
Committe Committe
d d write (A)
Active
Failed FAI
read (B) L
B = B + 50
Active End
Partial write (B)
Committe
d
Committe Commit
d
Failed Aborted

This is the initial state.

Discover
The statethat
afternormal executionhas
the transaction canbeen
no longer
rolledproceed.
back
The transaction stays in this state while it is
Oncethe
and a transaction
database has cannot
beenbe completed,
restored to itsany changes
state prior to
executing.
thatstart
the it made must
of the be undone rolling it back.
transaction.
Transaction State Diagram \ State Transition Diagram
} Active
Ê This is the initial state.
Ê The transaction stays in this state while it is executing.
} Partial Committed
Ê When a transaction executes its final operation/ instruction, it is said to be in a partially
committed state.
} Failed
Ê Discover that normal execution can no longer proceed.
Ê Once a transaction cannot be completed, any changes that it made must be undone rolling it
back.
} Committed
Ê The transaction enters in this state after successful completion of the transaction (after
committing transaction).
Ê We cannot abort or rollback a committed transaction.
} Aborted
Ê The state after the transaction has been rolled back and the database has been restored to its
state prior to the start of the transaction.
Section – 4
What is schedule?
} A schedule is a process of grouping the transactions into one and executing them in
a predefined order.
} A schedule is the chronological (sequential) order in which instructions are
executed in a system.
} A schedule is required in a database because when some transactions execute in
parallel, they may affect the result of the transaction.
} Means if one transaction is updating the values which the other transaction is
accessing, then the order of these two transactions will change the result of another
transaction.
} Hence a schedule is created to execute the transactions.
Example of schedule
Schedule Schedule
T1 T2 Execution
Read (A) A=B=1000
A = A - 50 Read (1000)
Write (A) A = 1000 - 50
Read (B) Write (950)
B = B + 50 Read (1000)
Write (B) B = 1000 + 50
Commit Write (1050)
Read (A) Commit
temp = A * 0.1 Read (950)
A = A - temp temp = 950 * 0.1
Write (A) A = 950 - 95
Read (B) Write (855)
B = B + temp Read (1050)
Write (B) B = 1050 + 95
Commit Write (1145)
Commit
Example of schedule
Schedule Schedule
T1 T2 Execution
Read (A) A=B=1000
Temp = A * 0.1 Read (1000)
A = A - temp Temp = 1000 * 0.1
Write (A) A = 1000 - 100
Read (B) Write (900)
B = B + temp Read (1000)
Write (B) B = 1000 + 100
Commit Write (1100)
Read (A) Commit
A = A - 50 Read (900)
Write (A) A = 900 - 50
Read (B) Write (850)
B = B + 50 Read (1100)
Write (B) B = 1100 + 50
Commit Write (1150)
Commit
Schedule 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.
Serial schedule
} A serial schedule is a schedule in which no transaction starts until a running
transaction has ended.
} A serial schedule is a schedule in which one transaction is executed completely
before starting another transaction.
} Transactions are executed one after the other.
} This type of schedule is called a serial schedule, as transactions are executed in a
serial manner.
Example of Serial Schedule
Serial Schedule Serial Schedule
T1 T2 T1 T2
Read (A) Read (A)
A = A - 50 A = A - 50
Write (A) Write (A)
Read (B) Read (B)
B = B + 50 B = B + 50
Write (B) Write (B)
Commit Commit
Read (A) Read (A)
temp = A * 0.1 temp = A * 0.1
A = A - temp A = A - temp
Write (A) Write (A)
Read (B) Read (B)
B = B + temp B = B + temp
Write (B) Write (B)
Commit Commit
Non-serial Schedule (Interleaved Schedule)
} Schedule that interleave the execution of different transactions.
} Means second transaction is started before the first one could end and execution
can switch between the transactions back and forth.
} It contains many possible orders in which the system can execute the individual
operations of the transactions.
Example of Non-serial Schedule (Interleaved Schedule)
Non-serial Schedule Non-serial Schedule
T1 T2 T1 T2
Read (A) Read (A)
A = A - 50 A = A - 50
Write (A) Write (A)
Read (A) Read (A)
temp = A * 0.1 temp = A * 0.1
A = A - temp A = A - temp
Write (A) Write (A)
Read (B) Read (B)
B = B + 50 B = B + 50
Write (B) Write (B)
Commit Commit
Read (B) Read (B)
B = B + temp B = B + temp
Write (B) Write (B)
Commit Commit
Equivalent Schedule
} If two schedules produce the same result after execution, they are said to be
equivalent schedule.
} They may yield the same result for some value and different results for another set
of values.
} That's why this equivalence is not generally considered significant.
Equivalent Schedule
Schedule-1 (A=B=1000) Schedule-2 (A=B=1000)
T1 T2 T1 T2
Read (A) Read (A)
A = A - 50 A = A - 50
Write (A) Write (A)
Read (A) Read (B)

In both schedules the sum “A + B” is

temp = A * 0.1 B = B + temp
A = A - temp Write (B)

Both schedules are

Write (A) Commit
Read (B) Read (A)
B = B + 50 temp = A * 0.1
Write (B) A = A - temp

equivalent
Commit Write (A)
Read (B) Read (B)

preserved.
B = B + temp B = B + 50
Write (B) Write (B)
Commit Commit
Serializability in DBMS
} A schedule is serializable if it is equivalent to a serial schedule.
} In serial schedules, only one transaction is allowed to execute at a time i.e. no
concurrency is allowed.
} Whereas in serializable schedules, multiple transactions can execute
simultaneously i.e. concurrency is allowed.

} Types (forms) of serializability

Ê Conflict serializability
Ê View serializability
Conflicting instructions
} Let li and lj be two instructions of transactions Ti and Tj respectively.

1. li = read(Q), lj = read(Q) Ti Tj Ti Tj
read (Q) read (Q)
li and lj don’t conflict
read (Q) read (Q)

2. li = read(Q), lj = write(Q) Ti Tj Ti Tj
read (Q) write(Q)
li and lj conflict
write(Q) read (Q)

3. li = write(Q), lj = read(Q) Ti Tj Ti Tj
li and lj conflict write(Q) read (Q)
read (Q) write(Q)

4. li = write(Q), lj = write(Q) Ti Tj Ti Tj
li and lj conflict write(Q) write(Q)
write(Q) write(Q)
Conflict serializability
} If a given schedule can be converted into a serial schedule by swapping its non-
conflicting operations, then it is called as a conflict serializable schedule.

} 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
Conflict serializability (Example)
T1 T2 T1 T2
Read (A) Read (A)
A = A - 50 A = A - 50
Write (A) Write (A)
Read (A) Read (B)
Temp = A * 0.1 B = B + 50
A = A - temp Write (B)
Write (A) Commit
Read (A)
Read (B) Temp = A * 0.1
B = B + 50 A = A - temp
Write (B) Write (A)
Commit Read (B) Read (B)
B = B + temp B = B + temp
Write (B) Write (B)
Commit Commit
Conflict Serializability (Example)
} Example of a schedule that is not conflict serializable:

T1 T2
Read (A)
Write (A)
Read (A)

} We are unable to swap instructions in the above schedule to obtain either the serial
schedule <T1, T2>, or the serial schedule <T2, T1>.
View serializability
} Let S1 and S2 be two schedules with the same set of transactions. S1 and S2 are
view equivalent if the following three conditions are satisfied, for each data item Q
Ê Initial Read
Ê Updated Read
Ê Final Write
} If a schedule is view equivalent to its serial schedule then the given schedule is said
to be view serializable.
Initial Read
} If in schedule S1, transaction Ti reads the initial value of Q, then in schedule S2 also
transaction Ti must read the initial value of Q.
S1 S3 S2
T1 T2 T1 T2 T1 T2
Read Read (A) Write
(A) Write Write Read (A)
(A) (A) (A)
} Above two schedules S1 and S3 are not view equivalent because initial read
operation in S1 is done by T1 and in S3 it is done by T2.
} Above two schedules S1 and S2 are view equivalent because initial read operation
in S1 is done by T1 and in S2 it is also done by T1.
Updated Read
} If in schedule S1 transaction Ti executes read(Q), and that value was produced by
transaction Tj (if any), then in schedule S2 also transaction Ti must read the value
of Q that was produced by transaction Tj.
S1 S3 S2
T1 T2 T3 T1 T2 T3 T1 T2 T3
Write (A) Write (A) Write (A)
Write (A) Write (A) Read (A)
Read (A) Read (A) Write (A)

} Above two schedules S1 and S3 are not view equal because, in S1, T3 is reading A
that is updated by T2 and in S3, T3 is reading A which is updated by T1.
} Above two schedules S1 and S2 are view equal because, in S1, T3 is reading A that
is updated by T2 and in S2 also, T3 is reading A which is updated by T2.
Final Write
} If Ti performs the final write on the data value in S1, then it also performs the final
write on the data value in S2.
S1 S3 S2
T1 T2 T3 T1 T2 T3 T1 T2 T3
Write (A) Write (A) Read (A)
Read (A) Write (A) Write (A)
Write (A) Read (A) Write (A)

} Above two schedules S1 and S3 are not view equal because final write operation in
S1 is done by T3 and in S3 final write operation is also done by T1.
} Above two schedules S1 and S2 are view equal because final write operation in S1
is done by T3 and in S2 also the final write operation is also done by T3.
View serializable example
} If a schedule is view equivalent to its serial schedule then the given schedule is said
to be view serializable.
Non-Serial Schedule (S1) Serial Schedule (S2)
T1 T2 T1 T2
Read (A) Read (A)
Write (A) Write (A)
Read (A) Read (B)
Write (A) Write (B)
Read (B) Read (A)
Write (B) Write (A)
Read (B) Read (B)
Write (B) Write (B)

} S2 is the serial schedule of S1. If we can prove that they are view equivalent then
we can says that given schedule S1 is view serializable.
View serializable example (Initial Read)
Non-Serial Schedule (S1) Serial Schedule (S2)
T1 T2 T1 T2
Read (A) Read (A)
Write (A) Write (A)
Read (A) Read (B)
Write (A) Write (B)
Read (B) Read (A)
Write (B) Write (A)
Read (B) Read (B)
Write (B) Write (B)

} In schedule S1, transaction T1 first reads the data item X. In S2 also transaction T1
first reads the data item X.
} In schedule S1, transaction T1 first reads the data item Y. In S2 also the first read
operation on Y is performed by T1.
} The initial read condition is satisfied for both the schedules.
View serializable example (Updated Read)
Non-Serial Schedule (S1) Serial Schedule (S2)
T1 T2 T1 T2
Read (A) Read (A)
Write (A) Write (A)
Read (A) Read (B)
Write (A) Write (B)
Read (B) Read (A)
Write (B) Write (A)
Read (B) Read (B)
Write (B) Write (B)

} In schedule S1, transaction T2 reads the value of X, written by T1. In S2, the same
transaction T2 reads the X after it is written by T1.
} In schedule S1, transaction T2 reads the value of Y, written by T1. In S2, the same
transaction T2 reads the value of Y after it is updated by T1.
} The updated read condition is also satisfied for both the schedules.
View serializable example (Final Write)
Non-Serial Schedule (S1) Serial Schedule (S2)
T1 T2 T1 T2
Read (A) Read (A)
Write (A) Write (A)
Read (A) Read (B)
Write (A) Write (B)
Read (B) Read (A)
Write (B) Write (A)
Read (B) Read (B)
Write (B) Write (B)

} In schedule S1, the final write operation on X is done by transaction T2. In S2 also
transaction T2 performs the final write on X.
} In schedule S1, the final write operation on Y is done by transaction T2. In schedule
S2, final write on Y is done by T2.
} The final write condition is also satisfied for both the schedules.
View serializable example
Non-Serial Schedule (S1) Serial Schedule (S2)
T1 T2 T1 T2
Read (A) Read (A)
Write (A) Write (A)
Read (A) Read (B)
Write (A) Write (B)
Read (B) Read (A)
Write (B) Write (A)
Read (B) Read (B)
Write (B) Write (B)

} Since all the three conditions that checks whether the two schedules are view
equivalent are satisfied in this example, which means S1 and S2 are view
equivalent.
} Also, as we know that the schedule S2 is the serial schedule of S1, thus we can say
that the schedule S1 is view serializable schedule.
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 var
char(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
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.
Question??