Advanced Database
Advanced Database
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:
• Update transactions: Inserts new records, deletes old records, or modifies existing
records in the database.
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.
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.
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
} 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.
} 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.
} 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??