Database Management Systems (DBMS)
GTU # 3130703
Unit-7
Transaction
Processing
Prof. Firoz A Sherasiya
Computer Engineering Department
Darshan Institute of Engineering & Technology, Rajkot
firoz.sherasiya@darshan.ac.in
9879879861
Outline
Looping
• What is transaction?
• ACID properties of transaction
• Transaction State Diagram \ State Transition
Diagram
• Schedule
• Two phase commit protocol
• Database recovery
• Concurrency
• Deadlock
What is transaction?
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 Rs. 50 from Account-A to Account-
B
Works as a single
logical unit
read (A)
A = A – 50
Transaction write (A) Operations
read (B)
B = B + 50
write (B)
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 4
ACID properties of transaction
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)
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 6
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 executed or
none. 0%
Either transaction execute 0% or 100%. read (A)
For example, consider a transaction to transfer Rs. 50 from A = A – 50
account A to account B. write (A)
FAI
In this transaction, if Rs. 50 is deducted from account A then it read (B) L
must be added to account B. B = B + 50
write (B)
100%
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 7
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 the execution of the read (A)
transaction as well. A = A – 50
In our example, total of A and B must remain same before and write (A)
after the execution of transaction. read (B)
B = B + 50
write (B)
A=450, B=550
A+B=1000
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 8
ACID properties of transaction (Isolation)
Changes occurring in a particular transaction will not be Start
visible to any other transaction until it has been committed. Transaction
Intermediate transaction results must be hidden from other read (A)
concurrently executed transactions. A = A – 50
In our example once our transaction starts from first step (step 1) write (A)
its result should not be access by any other transaction until last read (B)
step (step 6) is completed.
B = B + 50
write (B)
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 9
ACID properties of transaction (Durability)
After a transaction completes successfully, the changes it has A=500, B=500
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 result A = A – 50
must be stored permanently. It should not be removed if system write (A)
fails.
read (B)
B = B + 50
write (B)
A=450, B=550
These values must be stored
permanently in the database
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 10
Transaction State Diagram \
State Transition Diagram
Section – 3
Transaction State Diagram \ State Transition Diagram
The
When transaction enters
a transaction in this its
executes state after
final successful
operation, it is said to
completion of the
be in a partially transaction.
committed state. Aborted
Active
We cannot abort or rollback a committed transaction. read (A)
Partial
A = A – 50
Committed Committed
write (A) FAI
Active
Failed
read (B) L
B = B + 50
Active End
Partial write (B)
Committed
Committed
Commit
Failed Aborted
TheThis
stateisthat
Discover the initial
afternormal state.
executionhas
the transaction can no longer
been rolled backproceed.
and the
Thea transaction
Once
database transaction stays
cannot
has been restored inbe
this
itsstate
statewhile
to completed, ittoischanges
any
prior executing.
the start that it
of the
made must be undone rolling it back.
transaction.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 12
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 13
Schedule
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 15
Example of schedule
Schedule Schedule Execution
T1 T2 A=B=1000
Read (A) Read (1000)
A = A - 50 A = 1000 - 50
Write (A) Write (950)
Read (B) Read (1000)
B = B + 50 B = 1000 + 50
Write (B) Write (1050)
Commit Commit
Read (A) Read (950)
temp = A * 0.1 temp = 950 * 0.1
A = A - temp A = 950 - 95
Write (A) Write (855)
Read (B) Read (1050)
B = B + temp B = 1050 + 95
Write (B) Write (1145)
Commit Commit
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 16
Example of schedule
Schedule Schedule Execution
T1 T2 A=B=1000
Read (A) Read (1000)
Temp = A * 0.1 Temp = 1000 * 0.1
A = A - temp A = 1000 - 100
Write (A) Write (900)
Read (B) Read (1000)
B = B + temp B = 1000 + 100
Write (B) Write (1100)
Commit Commit
Read (A) Read (900)
A = A - 50 A = 900 - 50
Write (A) Write (850)
Read (B) Read (1100)
B = B + 50 B = 1100 + 50
Write (B) Write (1150)
Commit Commit
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 17
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 18
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
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 19
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 20
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
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 21
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 22
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
Both schedules are equivalent
Write (A) Write (A)
Read (A) Read (B)
temp = A * 0.1
In both schedules the sum “A + B” is
B = B + temp
A = A - temp Write (B)
Write (A) Commit
Read (B) Read (A)
B = B + 50 temp = A * 0.1
Write (B) A = A - temp
Commit Write (A)
Read (B) Read (B)
preserved.
B = B + temp B = B + 50
Write (B) Write (B)
Commit Commit
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 23
Serializability
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
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 24
Conflicting instructions
Let li and lj be two instructions of transactions Ti and Tj respectively.
Ti Tj Ti Tj
1. li = read(Q), lj = read(Q)
read (Q) read (Q)
li and lj don’t conflict read (Q) read (Q)
Ti Tj Ti Tj
2. li = read(Q), lj = write(Q) read (Q) write(Q)
li and lj conflict write(Q) read (Q)
Ti Tj Ti Tj
3. li = write(Q), lj = read(Q) write(Q) read (Q)
li and lj conflict read (Q) write(Q)
Ti Tj Ti Tj
4. li = write(Q), lj = write(Q) write(Q) write(Q)
li and lj conflict write(Q) write(Q)
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 25
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 26
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
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 27
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>.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 28
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 29
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)
(A) Write (A) Write (A) Read
(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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 30
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 31
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 32
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 33
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 34
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 35
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 36
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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 37
Two phase commit protocol
Section – 5
Two phase commit protocol
Two phase commit protocol ensures that all participants perform the same action (either
to commit or to rollback a transaction).
It is designed to ensure that either all the databases are updated or none of them, so that
the databases remain synchronized.
In two phase commit protocol there is one node which is act as a coordinator or controlling
site and all other participating node are known as cohorts or participant or slave.
Coordinator (controlling site) – the component that coordinates with all the participants.
Cohorts (Participants/Slaves) – each individual node except coordinator are participant.
As the name suggests, the two phase commit protocol involves two phases.
Commit request phase OR Prepare phase
Commit/Abort phase
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 39
Two phase commit protocol
Reque
st to p r e p
ar e
Prepare
Phase P r ep ar ed
Co m m
it/Abo
rt
Commit
Phase Done
Coordinator
Coordinator
Participant
Send inform
send
“ack” send
to to do
request
reply
inform
commit
asking for
whether ready
ready
commit to to
commit
done or
commit
or
notnot
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 40
Two phase commit protocol Commit Request Phase (Obtaining Decision)
Commit Request Phase (Obtaining Decision)
After each slave has locally completed its transaction, it sends a “DONE” message to the controlling
site.
When the controlling site has received “DONE” message from all slaves, it sends a “Prepare” (prepare
to commit) message to the slaves.
The slaves vote on whether they still want to commit or not.
If a slave wants to commit, it sends a “Ready” message.
A slave that does not want to commit sends a “Not Ready” message.
This may happen when the slave has conflicting concurrent transactions or there is a timeout.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 41
Two phase commit protocol Commit Phase (Performing
Decision)
Commit Phase (Performing Decision)
After the controlling site has received “Ready” message from all the slaves:
The controlling site sends a “Global Commit” message to the slaves.
The slaves commit the transaction and send a “Commit ACK” message to the controlling site.
When the controlling site receives “Commit ACK” message from all the slaves, it considers the
transaction as committed.
Commit Phase (Performing Decision)
After the controlling site has received the first “Not Ready” message from any slave:
The controlling site sends a “Global Abort” message to the slaves.
The slaves abort the transaction and send a “Abort ACK” message to the controlling site.
When the controlling site receives “Abort ACK” message from all the slaves, it considers the
transaction as aborted.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 42
Database recovery
Section – 6
Database recovery
There are many situations in which a transaction may not reach a commit or abort point.
Operating system crash
DBMS crash
System might lose power (power failure)
Disk may fail or other hardware may fail (disk/hardware failure)
Human error
In any of above situations, data in the database may become inconsistent or lost.
For example, if a transaction has completed 30 out of 40 write instructions to the database
when the DBMS crashes, then the database may be in an inconsistent state as only part of the
transaction’s work was completed.
Database recovery is the process of restoring the database and the data to a consistent
state.
This may include restoring lost data up to the point of the event (e.g. system crash).
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 44
Log based recovery method
The log is a sequence of log records, which maintains information about update
activities on the database.
A log is kept on stable storage (i.e HDD).
Log contains
Start of transaction
Transaction-id
Record-id
Type of operation (insert, update, delete)
Old value, new value
End of transaction that is committed or aborted.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 45
Log based recovery method
When transaction Ti starts, it registers itself by writing a record <Ti start> to the log.
Before Ti executes write(X), a log record <Ti, X, V1, V2> is written, where V1 is the value
of X before the write (the old value), and V2 is the value to be written to X (the new value).
When Ti finishes it last statement, the log record <Ti commit> is written.
Undo of a log record <Ti, X, V1, V2> writes the old value V1 to X
Redo of a log record <Ti, X, V1, V2> writes the new value V2 to X
Types of log based recovery method
Immediate database modification
Deferred database modification
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 46
Immediate v/s Deferred database modification
Immediate database modification Deferred database modification
Updates (changes) to the database are applied Updates (changes) to the database are
immediately as they occur without waiting to deferred (postponed) until the transaction
reach to the commit point. commits.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 47
Immediate v/s Deferred database modification
Immediate database modification Deferred database modification
A=500, B=600, A=500, B=600,
T1 T2
C=700 C=700
Read (A)
A = A - 100
Write (A)
<T1 start>
<T1 start> Read (B) <T1
<T1 start>
start>
<T1, A,
A, 500, 400>
400> B = B + 100 <T1,
<T1A, 400>
start>
<T1,
<T1 500,
start> <T1, A, 400>
<T1, B, 600, 700> Write (B) <T1, B, 700>
<T1,A,
<T1, B, 500,
600, 400>
700> <T1,
<T1, A,
B, 400>
700>
A=400,B=700,C=700 Commit A=500,B=600,C=700
<T1,
<T1, B,Commit>
600, 700> <T1,Commit>
<T1, B, 700>
Read (C)
<T2Commit>
<T1, start> <T1,
<T2Commit>
start>
C = C - 200
<T2,<T2
C, 700,
start>500> Write (C)
<T2C,
<T2, start>
500>
<T2,
<T2, C,Commit>
700, 500> Commit <T2,Commit>
<T2, C, 500>
A=400,B=700,C=50
A=400,B=700,C=500 A=400,B=700,C=70
A=400,B=700,C=50
0 0
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 48
Immediate v/s Deferred database modification
Immediate database modification Deferred database modification
Updates (changes) to the database are applied Updates (changes) to the database are
immediately as they occur without waiting to deferred (postponed) until the transaction
reach to the commit point. commits.
If transaction is not committed, then we If transaction is not committed, then no need
need to do undo operation and restart the to do any undo operations. Just restart the
transaction again. transaction.
If transaction is committed, then no need to If transaction is committed, then we need to
do redo the updates of the transaction. do redo the updates of the transaction.
Undo and Redo both operations are Only Redo operation is performed.
performed.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 49
Problems with Deferred & Immediate Updates (Checkpoint)
Searching the entire log is time consuming.
Immediate database modification
When transaction fail log file is used to undo the updates of transaction.
Deferred database modification
When transaction commits log file is used to redo the updates of transaction.
To reduce the searching time of entire log we can use check point.
It is a point which specifies that any operations executed before it are done correctly and
stored safely (updated safely in database).
At this point, all the buffers are force-fully written to the secondary storage (database).
Checkpoints are scheduled at predetermined time intervals.
It is used to limit:
Size of transaction log file
Amount of searching
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 50
How the checkpoint works when failure occurs
Time TC Tf
T1
T2
T3
T4
Checkpoint time Failure
At failure time:
Ignore the transaction T1 as it has already been committed before checkpoint.
Redo transaction T2 and T3 as they are active after checkpoint and are committed before failure.
Undo transaction T4 as it is active after checkpoint and has not committed.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 51
How the checkpoint works when failure occurs
Time TC TC Tf
T1
T2
T3
T4
T5
T6
Checkpoint time Checkpoint time Failure
Exercise Give the name of transactions which has already been committed before
checkpoint.
Exercise Give the name of transactions which will perform Redo
operation.
Exercise Give the name of transactions which will perform Undo
operation.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 52
Page table structure
1 2 1
2 1 2
3 4 3
4 101 4
5 202 :
. :
n n 101
Page Table :
:
The database is partitioned into fixed- 201
length blocks referred to as PAGES. Pages 202
n
Page table has n entries – one for
Pages on
each database page and each entry disk
contain pointer to a page on disk.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 53
Shadow paging technique
Shadow paging is an alternative to log-based recovery.
This scheme is useful if transactions execute serially.
It maintain two page tables during the lifetime of a transaction
current page table
shadow page table
Shadow page table is stored on non-volatile storage.
When a transaction starts, both the page tables are identical. Only current page table is
updated for data item accesses (changed) during execution of the transaction.
Shadow page table is never modified during execution of transaction.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 54
Shadow paging technique
Page 1 Page 1 Page 1
Page 2 Page
Page 2
2(old) Page 2 • Whenever any page is
Page 3 Page 3 Page 3 updated first time
Page 4 Page 4 Page 4 1. A copy of this page is made onto
an unused page
Page 5 Page
Page 5
5(old) Page 5 2. The current page table is then
Page 2(new) made to point to the copy
3. The update is performed on the
Page 5(new)
copy
Current page table Pages Shadow page table
Two pages - page 2 & 5 - are affected by a transaction and copied to new physical pages.
The current page table points to these pages.
The shadow page table continues to point to old pages which are not changed by the
transaction. So, this table and pages are used for undoing the transaction.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 55
Shadow paging technique
When transaction start, both the page tables are identical.
The shadow page table is never changed over the duration of the transaction.
The current page table will be changed when a transaction performs a write operation.
All input and output operations use the current page table.
Whenever any page is about to be written for the first time
A copy of this page is made onto an unused page
The current page table is then made to point to the copy
The update is performed on the copy
When the transaction completes, all the modifications which are done by transaction
which are present in current page table are transferred to shadow page table.
When the transaction fails, the shadow page table are transferred to current page table.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 56
Concurrency
Section – 7
What is concurrency?
Concurrency is the ability of a database to allow multiple (more than one) users to access
data at the same time.
Three problems due to concurrency
Lost update problem
Dirty read problem
Incorrect retrieval problem
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 58
Lost update problem
This problem indicate that if two transactions T1 and T2 X=10
both read the same data and update it then effect of first 0
T1 Time T2
update will be overwritten by the second update.
How to avoid: A transaction T2 must not update the data --- T0 ---
item (X) until the transaction T1 can commit data item Read X T1 ---
(X). --- T2 Read X
Update X
T3 ---
X=75
Update X
--- T4
X=50
--- T5 ---
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 59
Dirty read problem
The dirty read arises when one transaction update some X=10
item and then fails due to some reason. This updated item 0
T1 Time T2
is retrieved by another transaction before it is changed
back to the original value. --- T0 ---
How to avoid: A transaction T1 must not read the data --- T1
Update X
item (X) until the transaction T2 can commit data item X=50
(X). Read X T2 ---
--- T3 Rollback
--- T4 ---
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 60
Incorrect retrieval problem
The inconsistent retrieval problem arises Balance (A=200, B=250,
when one transaction retrieves data to T1 C=150)
Time T2
use in some operation but before it can Read (A)
use this data another transaction T1 ---
Sum 200
updates that data and commits. Read (B)
Through this change will be hidden from Sum Sum + 250 = T2 ---
first transaction and it will continue to use 450
previous retrieved data. This problem is --- T3 Read (C)
also known as inconsistent analysis Update (C)
--- T4
problem. 150 150 – 50 = 100
How to avoid: A transaction T2 must not --- T5 Read (A)
read or update data item (X) until the Update (A)
transaction T1 can commit data item --- T6 200 200 + 50 =
(X). 250
--- T7 COMMIT
Read (C)
T8 ---
Sum Sum + 100 = 550
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 61
What is lock?
A lock is a variable associated with data item to control concurrent access to that data
item.
Locking is a strategy that is used to
prevent such concurrent access of data.
Lock
variable
01
Database
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 62
Lock based protocol
Data items can be locked in two modes :
Shared (S) mode: When we take this lock we can just read the item but cannot write.
Exclusive (X) mode: When we take this lock we can read as well as write the item.
Lock-compatibility matrix T
1
T Exclusive
Shared lock
2 lock
Shared lock Yes No
Compatible Not Compatible
Exclusive No No
lock Not Compatible Not Compatible
A transaction may be granted a lock on an item if the requested lock is compatible with
locks already held on the item by other transactions.
If a lock cannot be granted, the requesting transaction is made to wait till all incompatible
locks held by other transactions have been released. The lock is then granted.
Any number of transactions can hold shared locks on an item, but if any transaction
holds an exclusive on the item no other transaction can hold any lock on the item.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 63
Lock based protocol
This locking protocol divides transaction execution phase into three parts:
1. When transaction starts executing, create a list of data items on which they need locks and requests
the system for all the locks it needs.
2. Where the transaction acquires all locks and no other lock is required. Transaction keeps executing
its operation.
3. As soon as the transaction releases its first lock, the third phase starts. In this phase a transaction
cannot demand for any lock but only releases the acquired locks.
Transaction
Lock acquisition execution Lock releasing
phase phase
Transaction
Transaction Transaction Time
begin end
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 64
Two phase locking protocol
This protocol works in two phases,
1. Growing Phase
In this phase a transaction obtains locks, but can not release any lock.
When a transaction takes the final lock is called lock point.
2. Shrinking Phase
In this phase a transaction can release locks, but can not obtain any lock.
The transaction enters the shrinking phase as soon as it releases the first lock after crossing the Lock
Point.
Growing phase Shrinking phase
Transaction
Transaction Transaction Time
begin end
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 65
Strict two phase locking protocol V/S Rigorous two phase locking protocol
Strict two phase locking protocol
In this protocol, a transaction may release all the shared locks after the Lock Point has been reached,
but it cannot release any of the exclusive locks until the transaction commits or aborts.
It ensures that if data is being modified by one transaction, then other transaction cannot read it
until first transaction commits.
This protocol solves dirty read problem.
Rigorous two phase locking protocol
In this protocol, a transaction is not allowed to release any lock (either shared or exclusive) until it
commits.
This means that until the transaction commits, other transaction can not acquire even a shared lock
on a data item on which the uncommitted transaction has a shared lock.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 66
Time stamp based protocol
This protocol uses either system time or logical counter to be used as a time-stamp.
Every transaction has a time-stamp associated with it and the ordering is determined by
the age of the transaction.
A transaction ‘T1’ created at 0002 clock time would be older than all other transaction, which
come after it.
For example, any transaction ‘T2' entering the system at 0004 is two seconds younger than
transaction ‘T1’ and priority is given to the older one.
In addition, every data item is given the latest read and write time-stamp. This lets the
system know, when last read and write operations was made on the data item.
This is the responsibility of the protocol system that the conflicting pair of tasks should be
executed according to the timestamp values of the transactions.
Time-stamp 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).
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 67
Time stamp ordering protocol
This is the responsibility of the protocol system that the conflicting pair of tasks should be
executed according to the timestamp values of the transactions.
Time-stamp 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 read(X) operation:
If TS(Ti) < W-timestamp(X)
• Operation rejected.
If TS(Ti) >= W-timestamp(X)
• Operation executed.
If a transaction Ti issues 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.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 68
Deadlock
Section – 8
What is deadlock?
Consider the following two transactions:
T1 T2
Granted for (A) Lock-X (A)
Write (A)
Lock-X (B) Granted for (B)
Write (B)
Lock-X (A) Waiting for (A)
Write (A)
Waiting for (B) Lock-X (B)
Write (B)
A deadlock is a situation in which two or more transactions are waiting for one another
to give up locks.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 70
Deadlock detection
A simple way to detect deadlock is with the help of wait-for graph.
One node is created in the wait-for graph for each transaction that is currently executing.
Whenever a transaction Ti is waiting to lock an item X that is currently locked by a
transaction Tj, a directed edge from Ti to Tj (Ti→Tj) is created in the wait-for graph.
When Tj releases the lock(s) on the items that Ti was waiting for, the directed edge is
dropped from the wait-for graph.
We have a state of deadlock if and only if the wait-for graph has a cycle.
Then each transaction involved in the cycle is said to be deadlocked.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 71
Deadlock detection
Transaction A is waiting for transactions B and C.
Transactions C is waiting for transaction B. B D
Transaction B is waiting for transaction D.
This wait-for graph has no cycle, so there is no deadlock state. A
CK LO
AD
Suppose now that transaction D is requesting an item held by C.
DE
Then the edge D → C is added to the wait-for graph. C
Now this graph contains the cycle.
B→D→C→B
It means that transactions B, D and C are all deadlocked.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 72
Deadlock recovery
When a deadlock is detected, the system must recover from the
deadlock. B D
The most common solution is to roll back one or more
transactions to break the deadlock. A
CK LO
Choosing which transaction to abort is known as victim
AD
selection.
DE
C
In this wait-for graph transactions B, D and C are deadlocked.
In order to remove deadlock one of the transaction out of these
three (B, D, C) transactions must be roll backed.
We should rollback those transactions that will incur the
minimum cost.
When a deadlock is detected, the choice of which transaction to
abort can be made using following criteria:
The transaction which have the fewest locks
The transaction that has done the least work
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 73
Deadlock prevention
A protocols ensure that the system will never enter into a deadlock state.
Some prevention strategies :
Require that each transaction locks all its data items before it begins execution (pre-declaration).
Impose partial ordering of all data items and require that a transaction can lock data items only in
the order specified by the partial.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 74
Deadlock prevention
Following schemes use transaction timestamps for the sake of deadlock prevention alone.
1. Wait-die scheme — non-preemptive
If an older transaction is requesting a resource which is held by younger transaction, then older
transaction is allowed to wait for it till it is available.
If an younger transaction is requesting a resource which is held by older transaction, then younger
transaction is killed.
2. Wound-wait scheme — preemptive
If an older transaction is requesting a resource which is held by younger transaction, then older
transaction forces younger transaction to kill the transaction and release the resource.
If an younger transaction is requesting a resource which is held by older transaction, then younger
transaction is allowed to wait till older transaction will releases it.
Wait-die Wound-wait
O needs a resource held by O waits Y dies
Y
Y needs a resource held by Y dies Y waits
O
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 75
Deadlock prevention
Following schemes use transaction timestamps for the sake of deadlock prevention alone.
3. Timeout-Based Schemes
A transaction waits for a lock only for a specified amount of time. After that, the wait times out and
the transaction is rolled back. So deadlocks never occur.
Simple to implement; but difficult to determine good value of the timeout interval.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 76
Questions asked in GTU
1. Write a note on two phase locking protocol.
2. Explain ACID properties of transaction with suitable example.
3. What is log based recovery? Explain immediate database modification technique for
database recovery. OR Define Failure. Write a note on log based recovery.
4. State differences between conflict serializability and view serializability.
5. Explain two-phase commit protocol.
6. Define transaction. Explain various states of transaction with suitable diagram.
7. Write differences between shared lock and exclusive lock.
8. Explain deadlock with suitable example.
9. What is locking? Define each types of locking.
10. Define wait-Die & wound-wait.
Prof. Firoz A Sherasiya #3130703 (DBMS) Unit 7 – Transaction Processing 77
Database Management Systems (DBMS)
GTU # 3130703
Thank
You
Prof. Firoz A Sherasiya
Computer Engineering Department
Darshan Institute of Engineering & Technology, Rajkot
firoz.sherasiya@darshan.ac.in
9879879861