Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Transaction Management

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 26

TRANSACTION

MANAGEMENT
Database Management System
Transaction Management

 A transaction is a logical unit of processing in a


DBMS which entails one or more database access
operation.
 Simple Transaction Example
1. Read your account balance
2. Deduct the amount from your balance
3. Write the remaining balance to your account
4. Read your friend’s account balance
5. Add the amount to his account balance
6. Write the new updated balance to his account
ACID Properties
 In order to ensure that a transaction is completed
fully, it defines four properties of it.
 In a database, each transaction should maintain
ACID property to meet the consistency and integrity
of the database.
 Atomicity
 Consistency
 Isolation
 Durability
Atomicity
 This property states that each transaction must be
considered as a single unit and must be completed
fully or not completed at all.
 No transaction in the database is left half
completed. Database should be in a state either
before the transaction execution or after the
transaction execution.
 It should not be in a state ‘executing’.
Consistency
 Any transaction should not inject any incorrect or
unwanted data into the database. It should maintain
the consistency of the database.
 Once the transaction is executed, it should move
from one consistent state to another.
 It means that transaction should leave the database
consistent.
Isolation
 If there are multiple transactions executing
simultaneously, then all the transaction should be
processed as if they are single transaction.
 But individual transaction in it should not alter or
affect the other transaction.
 That means each transaction should be executed as
if they are independent.
Durability
 After successful completion of a transaction, the changes
in the database should persist. Even in the case of
system failures.
 The database should be strong enough to handle any
system failure. It should not be working for single
transaction alone. It should be able to handle multiple
transactions too.
 If there is any set of insert /update, then it should be
able to handle and commit to the database.
 If there is any failure, the database should be able to
recover it to the consistent state.
What is a Schedule?
 A Schedule is a process creating a single group of
the multiple parallel transactions and executing
them one by one.
 It should preserve the order in which the instructions
appear in each transaction.
 If two transactions are executed at the same time,
the result of one transaction may affect the output
of other.
Transaction and Scheduling
 Parallel execution in a database is inevitable. But,
Parallel execution is permitted when there is an
equivalence relation amongst the simultaneously
executing transactions.
 This equivalence is of 3 Types.
 RESULT EQUIVALENCE
 View Equivalence
 CONFLICT Equivalence
Transaction and Scheduling
 RESULT EQUIVALENCE
 If two schedules display the same result after
execution, it is called result equivalent schedule.
 They may offer the same result for some value and
different results for another set of values.
 For example, one transaction updates the product
quantity, while other updates customer details.
Transaction and Scheduling
 View Equivalence
 View Equivalence occurs when the transaction in
both the schedule performs a similar action.
 Example, one transaction inserts product details in
the product table, while another transaction inserts
product details in the archive table.
 The transaction is the same, but the tables are
different.
Transaction and Scheduling
 CONFLICT Equivalence
 In this case, two transactions update/view the same
set of data.
 There is a conflict amongst transaction as the order
of execution will affect the output.
Serializability

 When multiple transactions are being executed by


the operating system in a multiprogramming
environment, there are possibilities that instructions
of one transactions are interleaved with some other
transaction.
Control concurrent Access
14

 Problem–in a multi-user environment,


simultaneous access to data can result in
interference and data loss (lost update
problem)
 Solution–Concurrency Control
 The process of managing simultaneous
operations against a database so that
data integrity is maintained and the
operations do not interfere with each other
in a multi-user environment
Lost update (no concurrency control in effect)

15

Simultaneous access causes updates to cancel each other.


A similar problem is the inconsistent read problem.
16
Concurrency Control Techniques
 Serializability
 Finish one transaction before starting another
 Locking Mechanisms
 The most common way of achieving serialization
 Data that is retrieved for the purpose of updating is
locked for the updater
 No other user can perform update until unlocked
Figure 11-11: Updates with locking (concurrency control)

This prevents the lost update problem


17
17
Locking Mechanisms
18

 Locking level:
 Database–used during database updates
 Table–used for bulk updates
 Block or page–very commonly used
 Record–only requested row; fairly commonly used
 Field–requires significant overhead; impractical

 Types of locks:
 Shared lock–Read but no update permitted. Used when
just reading to prevent another user from placing an
exclusive lock on the record
 Exclusive lock–No access permitted. Used when
preparing to update
Deadlock
19

 An impasse that results when two or more transactions have


locked common resources, and each waits for the other to
unlock their resources

Figure 11-12
The problem of deadlock

John and Marsha will wait


forever for each other to release
their locked resources!
Managing Deadlock
20

 Deadlock prevention:
 Lock all records required at the beginning of a
transaction
 Two-phase locking protocol
 Growing phase
 Shrinking phase
 May be difficult to determine all needed resources in
advance
 Deadlock Resolution:
 Allow deadlocks to occur
 Mechanisms for detecting and breaking them
 Resource usage matrix
Deferred Update vs Immediate
Update
 Deferred Update and Immediate Update are two
techniques used to maintain transaction log files of
Database Management Systems (DBMS).
 Transaction log (also referred to as the journal log
or the redo log) is a physical file that stores the
Transaction ID, the time stamp of the transaction, the
old value and the new values of the data.
Deferred Update vs Immediate
Update
 This allows the DBMS to keep track of the data
before and after each transaction.
 When the transactions are committed and the
database is returned to a consistent state, the log
might be truncated to remove the committed
transactions.
Deferred Update vs Immediate
Update
 Deferred update also called NO-UNDO/REDO is a
technique used to recover/support transaction failures
that occur due to operating system, power, memory or
machine failures.
 When a transaction runs, any updates or alterations
made to the database by the transaction are not done
immediately.
 They are recorded in the log file. Data changes
recorded in the log file are applied to the database on
commit.
 This process is called “Re-doing”.
Deferred Update vs Immediate
Update
 On rollback, any changes to data recorded in the log
file are discarded; hence no changes will be applied to
the database.
 If a transaction fails and it is not committed due to any
of the reasons mentioned above, the records in the log
file are discarded and the transaction is restarted.
 If the changes in a transaction are committed before
crashing, then after the system restarts, changes
recorded in the log file are applied to the database.
Deferred Update vs Immediate
Update
 Immediate update also called UNDO/REDO, is also
another technique used to recover/support
transaction failures that occur due to operating
system, power, memory or machine failures.
 When a transaction runs, any of the updates or
alterations made by the transaction are written
directly in to the database. Both the original values
and the new values are also recorded in the log file
before changes are made to the database.
Deferred Update vs Immediate
Update
 On commit all changes made to the database are
made permanent and the records in the log file are
discarded.
 On rollback old values are restored in to the database
using the old values stored in the log file.
 All the changes made by transactions to the database
are discarded and this process is called “Un-doing”.
When the system restarts after a crash, all the
database changes are made permanent for committed
transactions. For uncommitted transactions, original
values are restored using the values in the log file.

You might also like