PARULINSTITUTEOF ENGINEERING &TECHNOLOGY

FACULTY OF ENGINEERING & TECHNOLOGY

PARULUNIVERSITY

Subject: Database Management System

Unit 6 : Transactions
Computer Science & Engineering
Nilesh Khodifad (Assistant Prof. PIET-CSE)
Transaction

- Transaction is a part of program execution that accesses and updates various

data items.
- A transaction can be defined as a group of tasks in which a single task is the
minimum processing unit of work, which cannot be divided further.
- A transaction is a logical unit of work that contains one or more SQL
statements.
- A transaction is an atomic unit.
- A database transaction must be atomic, meaning that is must be either
entirely completed or aborted.
ACID properties
- 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 executed or
none.

- Either transaction execute 0% or 100%.

- For example, consider a transaction to transfer Rs. 50 from account A

to account B.

- In this transaction, if Rs. 50 is deducted from account A then it must

be added to account B.
ACID properties of transaction (Isolation)
- Changes occurring in a particular transaction will not be visible to any
other transaction until it has been committed.

- Intermediate transaction results must be hidden from other concurrently

executed transactions.

- In our example once our transaction starts from first step (step 1) its result
should not be access by any other transaction until last step (step 6) is
completed.
ACID properties of transaction (Durability)

- After a transaction completes successfully, the changes it has made to the

database persist (permanent), even if there are system failures.

- Once our transaction completed up to last step its result must be stored
permanently. It should not be removed if system fails.
Transaction State Diagram
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.
Scheduling

- 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 Scheduling
Types of Scheduling
- Serial Scheduling : 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.

- Non Serial Scheduling : 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.

- Equivalent Scheduling : 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.
Example of Serial Schedule
Example of Non Serial Schedule
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
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.

- Conflicting Operations : A pair of operations are said to be

conflicting operations if they follow the set of conditions given below:

- Each operation is a part of different transactions.

- Both operations are performed on the same data item.
- One of the performed must be a write operation.
Example of Conflict Serializability
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.
Example of View Serializability - 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.

- 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.
Example of View Serializability - 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.

- 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.
Example of View Serializability - 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.

- 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.
-
 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
Two phase commit protocol

Prepar
e
Phase

Commit
Phase
Coordinator
Coordinator
Participant
Send inform
send
send
“ack” to to
reply
inform
do commit
request
whether asking
ready for
commit ready
todone
to commit
commit
or not or not
 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.
 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.
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).
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.
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
Immediate vs Deferred database modification
- Immediate database modification : Updates (changes) to the database are applied immediately
as they occur without waiting to reach to the commit point.
- If transaction is not committed, then we need to do undo operation and restart the transaction again.
If transaction is committed, then no need to do redo the updates of the transaction. Undo and Redo
both operations are performed

- Deferred database modification : Updates (changes) to the database are deferred (postponed)
until the transaction commits.
- If transaction is not committed, then no need to do any undo operations. Just restart the transaction.
If transaction is committed, then we need to do redo the updates of the transaction.Only Redo
operation is performed.
Problems with Deferred and Immediate Updates
(Checkpoints)
- 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
H- oAw
t failure time:
the checkpoint works when failure occurs
- 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
Page Table Structure

-The database is partitioned into fixed

length blocks referred to as PAGES.

- Page table has n entries - one for

each database page and each entry
contain pointer to a page on disk.
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.
Shadow paging technique

Whenever page is updated 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

- 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.
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.
Introduction to Concurency Control
● Concurrency control is a set of mechanisms and techniques used to ensure that multiple
transactions can access and modify the database concurrently without leading to data
inconsistency.

● It ensures that the database remains in a consistent state even when multiple transactions are
executed simultaneously.
● Why concurrency control is important?
● In a multi-user database environment, several transactions may try to access the same data
simultaneously. Without proper concurrency control, this can lead to various problems such as:
• Lost Update
• Dirty Read
• Non-Repeatable Read
Introduction to Concurency Control
• Lost Updates: When two transactions update the same data simultaneously, and one of the
updates is lost.

• Dirty Reads: When a transaction reads data that has been modified by another transaction but
not yet committed.

• Non-Repeatable Reads: When a transaction reads the same data multiple times and finds
different values because another transaction has updated the data in between.
Concurency Control Mechanism
● To handle the issues that arise from concurrent transactions, several concurrency control mechanisms
are employed. Protocols are used to maintain ACID properties of all the transaction.

● Lock-Based Protocols:

● Lock-based protocols are a fundamental aspect of concurrency control in Database Management

Systems (DBMS). They ensure that multiple transactions can safely access and modify the database
concurrently without causing inconsistencies.

● Locks are mechanisms that restrict access to data items to prevent conflicting operations from occurring
simultaneously.
Types of Locks
Shared Lock (S-lock):
• Allows multiple transactions to read a data item.
• Prevents any transaction from modifying the data item.
• Multiple transactions can hold shared locks on the same data item simultaneously.

Exclusive Lock (X-lock):

• Allows a single transaction to read and modify a data item.

• Prevents any other transaction from reading or modifying the data item.
• Only one transaction can hold an exclusive lock on a data item at any time.
Multi Granularity tree Hierarchy
Multi Granularity tree
The highest level represents the entire database. Below it is nodes of type area; the database
consists of exactly these areas. The area has children nodes which are called files. Every area has
those files that are its child nodes. No file can span more than one area.

Finally, each file has child nodes called records and no record is present in more than one file.
Timestamp based Protocol
Lock based protocols ensure conflict serializability but it causes 2 problems:
➢ Deadlock and
➢ Starvation

Timestamp-Based Protocols
❑The Timestamp methods for concurrency control does not need any locks and
therefore there are no deadlocks.
❑ Locking methods generally prevent conflicts by making transactions to wait.
❑ Timestamp methods do not make the transactions wait.
❑In this method, Transactions involved in a conflict are simply rolled back and
restarted.
● The most commonly used concurrency protocol is the timestamp based protocol. This protocol uses
either system time or logical counter as a timestamp.
● Lock-based protocols manage the order between the conflicting pairs among transactions at the
time of execution, whereas timestamp-based protocols start working as soon as a transaction is
Timestamp based Protocol

❑ Every transaction has a timestamp associated with it, and the ordering is determined by the age of the
transaction. A transaction created at 0002 clock time would be older than all other transactions that come
after it. For example, any transaction 'y' entering the system at 0004 is two seconds younger and the
priority would be given to the older one.

❑In addition, every data item is given the latest read and write-timestamp. This lets the system know
when the last ‘read and write’ operation was performed on the data item.
Introduction - Deadlock
● Deadlock in a database management system (DBMS) is a situation where
two or more processes are blocked, waiting for each other to release
a resource that they need to proceed with their execution.
● This creates a circular wait, where each process is waiting for a resource
that is held by another process, leading to a complete blockage of the
system.
● Deadlocks can occur in multi-user, multi-tasking environments, where
multiple processes are accessing shared resources simultaneously and
can cause decreased system performance or system failure if not
resolved.
Introduction - Deadlock
Introduction - Deadlock - Example

1. Assume T1 has a lock on some rows in the

Employees database and needs to change
some rows in the Salary table.
2. Simultaneously, Transaction T2 has locks on
the Salary table rows (which T1 needs to
update) but needs to update the Employees
table rows held by Transaction T1.
Introduction - Deadlock - Example

● Mutual Exclusion: At least one resource must be held in a non-shareable

mode, meaning only one process can access it at a time.
● Hold and Wait: A process is holding at least one resource and is waiting for
additional resources that are currently held by other processes.
● No Preemption Condition: Resources cannot be taken away from a process
and given to another process.
● Circular Wait: A set of processes are waiting for resources held by each
other, forming a circular chain.
● When all four conditions are met, a deadlock occurs, and the processes
involved are unable to proceed or release their resources. This results in a
situation where the system cannot continue processing transactions
Deadlocks

● Detection
○ Wait-for graph
● Prevention
○ Resource ordering
○ Timeout
○ Wait-die
○ Wound-wait
Deadlock Detection
● Deadlock detection is a technique used in DBMS to identify and resolve
deadlocks.
● In this technique, the system continuously checks for deadlocks and, if
found, takes appropriate action to resolve the deadlock.
● When a transaction waits indefinitely to obtain a lock, The database
management system should detect whether the transaction is involved in a
deadlock or not.
● The lock manager maintains a Wait for the graph to detect the deadlock
cycle in the database.
Deadlock Detection - Wait for Graph

● Suitable method for deadlock detection.

● In this method, a graph is created based on the transaction and their lock.
● If the created graph has a cycle or closed loop, then there is a deadlock.
● The wait for the graph is maintained by the system for every
transaction which is waiting for some data held by the others.
● The system keeps checking the graph if there is any cycle in the graph.
Deadlock Detection - Wait for Graph
Deadlock Detection

● Deadlock detection is an important technique for ensuring the correct

functioning of a DBMS.
● It allows the system to identify and resolve deadlocks in a timely
manner, reducing the risk of system failure.
● However, it can also lead to decreased system performance as a result
of the additional overhead required for monitoring and controlling
resource allocation.
Deadlock Prevention

● A deadlock can be prevented if the resources are allocated in such a way

that a deadlock never occurs.
● The DBMS examines the operations to see if they can cause a deadlock.
● If they do, the transaction is never permitted to be executed.
● Deadlock prevention Mechanisms are as follows:
○ Wait-Die,
○ Wound-Wait
○ Timeout-Based Approach
Deadlock Prevention - Wait and Die

● If a transaction requests a resource that is locked by another transaction,

then the DBMS simply checks the timestamp of both transactions and
allows the older transaction to wait until the resource is available for
execution.
Deadlock Prevention - Wait and Die
● Example:
● two transactions T1 and T2, TS(T)-timestamp of transaction T.
Resource(R)
○ T2 is holding the R and has locked.
○ T1 requests for R.
● Step 1: TS(T1)<TS(T2)-T1 is older transaction. T1 will wait for the
resource R until its available.
● Step2: If T1 is an older transaction and has held some resource with it and
if T2 is waiting for it, then T2 is killed and restarted later with random delay
but with the same timestamp.
● This scheme allows the older transaction to wait but kills the younger one.
Deadlock Prevention - Wound and Wait

● When an older transaction demands a resource that is already locked

by a younger transaction (a transaction that is initiated later), the younger
transaction is forced to kill/stop its processing and release the locked
resource for the older transaction's own execution.
● The younger transaction is now restarted with a one-minute delay, but the
timestamp remains the same.
● If a younger transaction requests a resource held by an older one, the
younger transaction is made to wait until the older one releases the
resource.
Deadlock Prevention - Time out based approach

● A transaction waits for a lock only for a specified amount of time. After the
wait time is out and the transaction is rolled back. (No deadlock!)
Thank You