Transaction Management
Transaction Management
Transaction Management
MANAGEMENT
Database Management System
Transaction Management
15
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
Figure 11-12
The problem of deadlock
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.