DBMS Transaction Management
DBMS Transaction Management
DBMS Transaction Management
All types of database access operation which are held between the beginning and
end transaction statements are considered as a single logical transaction in DBMS.
During the transaction the database is inconsistent. Only once the database is
committed the state is changed from one consistent state to another.
Facts about Database Transactions
A transaction is a program unit whose execution may or may not change the
contents of a database.
The transaction concept in DBMS is executed as a single unit.
If the database operations do not update the database but only retrieve data,
this type of transaction is called a read-only transaction.
A successful transaction can change the database from one CONSISTENT
STATE to another
DBMS transactions must be atomic, consistent, isolated and durable
If the database were in an inconsistent state before a transaction, it would
remain in the inconsistent state after the transaction.
Active State A transaction enters into an active state when the execution
process begins. During this state read or write operations can
be performed.
Partially Committed A transaction goes into the partially committed state after the
end of a transaction.
Failed State A transaction considers failed when any one of the checks fails
or if the transaction is aborted while it is in the active state.
In a database system where more than one transaction are being executed
simultaneously and in parallel, the property of isolation states that all the
transactions will be carried out and executed as if it is the only transaction in
the system. No transaction will affect the existence of any other transaction.
The database should be durable enough to hold all its latest updates even if
the system fails or restarts. If a transaction updates a chunk of data in a
database and commits, then the database will hold the modified data. If a
transaction commits but the system fails before the data could be written on
to the disk, then that data will be updated once the system springs back into
action.
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.
For example: Suppose there are two transactions T1 and T2 which have some
operations. If it has no interleaving of operations, then there are the following two
possible outcomes:
1. Execute all the operations of T1 which was followed by all the operations of
T2.
2. Execute all the operations of T1 which was followed by all the operations of
T2.
o In the given (a) figure, Schedule A shows the serial schedule where T1
followed by T2.
o In the given (b) figure, Schedule B shows the serial schedule where T2
followed by T1.
2. Non-serial Schedule
o If interleaving of operations is allowed, then there will be non-serial
schedule.
o It contains many possible orders in which the system can execute the
individual operations of the transactions.
o In the given figure (c) and (d), Schedule C and Schedule D are the non-serial
schedules. It has interleaving of operations.
3. Serializable schedule
o The serializability of schedules is used to find non-serial schedules that
allow the transaction to execute concurrently without interfering with one
another.
o It identifies which schedules are correct when executions of the transaction
have interleaving of their operations.
o A non-serial schedule will be serializable if its result is equal to the result of
its transactions executed serially.
Here,