Transaction Management

Transaction
• A transaction is a unit of program execution
that accesses and possibly updates various
data items.
• E.g. transaction to transfer $50 from account A
to account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
 The ACID properties
• Atomicity: Either all actions are carried out, or none
are
• Consistency: If each transaction is consistent, and
the database is initially consistent, then it is left
consistent
• Isolation: Transactions are isolated, or protected,
from the effects of other scheduled transactions
• Durability: If a transactions completes successfully,
then its effects persist

3
 AAtomicity
• A transaction can
– Commit after completing its actions, or
– Abort because of
• Internal DBMS decision: restart
• System crash: power, disk failure, …
• Unexpected situation: unable to access disk, data value, …
• A transaction interrupted in the middle could leave the
database inconsistent
• DBMS needs to remove the effects of partial transactions to
ensure atomicity: either all a transaction’s actions are
performed or none

4
 Consistency
• Users are responsible for ensuring transaction consistency
– when run to completion against a consistent database instance, the
transaction leaves the database consistent
• For example, consistency criterion that my inter-account-
transfer transaction does not change the total amount of
money in the accounts!

• Database consistency is the property that every transaction

Integrity
sees a consistent database instance. It follows from Constraints!
transaction atomicity, isolation and transaction consistency

5
 Isolation
• Guarantee that even though transactions may be
interleaved, the net effect is identical to executing
the transactions serially
• For example, if transactions T1 and T2 are executed
concurrently, the net effect is equivalent to executing
– T1 followed by T2, or
– T2 followed by T1
• NOTE: The DBMS provides no guarantee of effective
order of execution

6
 Durability
• DBMS uses the log to ensure durability
• If the system crashed before the changes made
by a completed transaction are written to disk,
the log is used to remember and restore these
changes when the system is restarted

7
States of Transactions
A transaction in a database can be in one of the following states −
Active − In this state, the transaction is being executed. This is the initial state of every
transaction.

Partially Committed − When a transaction executes its final operation, it is said to be in a

partially committed state.

Failed − A transaction is said to be in a failed state if any of the checks made by the database
recovery system fails. A failed transaction can no longer proceed further.

Aborted − If any of the checks fails and the transaction has reached a failed state, then the
recovery manager rolls back all its write operations on the database to bring the database
back to its original state where it was prior to the execution of the transaction. Transactions
in this state are called aborted. The database recovery module can select one of the two
operations after a transaction aborts −
Re-start the transaction
Kill the transaction

Committed − If a transaction executes all its operations successfully, it is said to be

committed. All its effects are now permanently established on the database system.
 TRANSACTION STATE
• States of Transaction…
•  A transaction has Committed only if it has
entered the Committed State.
•  A transaction has Aborted only if it has
entered the Aborted State.
•  A transaction is said to have terminated if it
has either Committed or Aborted.
Processes of Transaction 
Transaction is executed as a series of Reads and Writes of database objects
which are:
Read Operation
Write Operation

Read Operation Data object is first brought into Main Memory from Disk, and
then value is copied into a Program.

 Write Operation Data base object copy in Main Memory is first modified
then written to Disk.
Example Let T1 be a transaction that transfers Rs. 50 from A/C A to A/C B.
A/C= 1000 A/C B=2000

T1 Schedule
Read (A, a)
a=a-50
Write (A, a)
Read (B, b)
B=b+50
Write (B, b)
 Concurrent Executions
• Multiple transactions are allowed to run
concurrently in the system. i.e. more than one
transaction at the same time. The technique of
interleaving of execution of two transaction is
used.T1 execute then T2 and then T1 again
T1 T2

Read(A)
Write(A)
Read(B)
Write(B);
Read(c)
Write(c)
 Advantages of Concurrent Execution of
Transaction
• Improved Throughput Average no. of
transactions completed in a given time (CPU
Waiting).
•  Reduced Waiting Time Short transaction can
complete quickly.
• Better Disk Utilization
 Schedules
• Schedule – a sequences of instructions that specify the chronological
order in which instructions of concurrent transactions are executed. A
schedule is a list of actions from a set of transactions
– a schedule for a set of transactions must consist of all instructions of those
transactions
– must preserve the order in which the instructions appear in each individual
transaction. for example
[RT1(a), WT1(a), RT2(b), WT2(b), RT1(c), WT1(c)] is a well-formed schedule

• A transaction that successfully completes its execution will have a

commit instructions as the last statement
– by default transaction assumed to execute commit instruction as its last step
• A transaction that fails to successfully complete its execution will
have an abort instruction as the last statement
 Scheduling of Transactions
• Complete Schedule
• Serial Schedule
• Non-Serial Schedule
• Equivalent Schedule
 Complete Schedule
• A schedule that contains either an abort or a
commit for each transaction whose actions are
listed in it is called a complete schedule.

• Serial schedule if the actions of different

transactions are executed from start to finish
then the schedule is called as a serial
schedule.
 Schedule 1
• Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from A
to B.
• A serial schedule in which T1 is followed by T2 :
 NON SERIAL SCHEDULE
• A schedule in which the operations from a set of
concurrent transactions are interleaved is called
as a non serial schedule .

T1 T2

A=a*10
A=a/100
B=b-10
B=b*4
 Schedule 3
• Let T1 and T2 be the transactions defined previously. The following schedule is not a serial schedule, but it is
equivalent to Schedule 1.

In Schedules 1, 2 and 3, the sum A + B is preserved.

 EQUIVALENT SCHEDULE

Two schedules are said to be equivalent schedules if they produce the same result on any
database state. Equivalent schedules always produce identical results.
 Serializability
• A (possibly concurrent) schedule is serializable if
it is equivalent to a serial schedule.
• Objective: Is to find non-serial schedule that allow
the transaction to execute concurrently without
interfering with one another and thereby producing
a database state that could be produced by a serial
execution.
 Conflicts of Operations
• Those Read/Write operations whose order cannot be
changed without affecting the Consistency of data
are called Conflict Operations.
•  Some rules for conflict operations
•  If 2 transactions only Read a data object, they do
not conflict.
•  If 2 transactions either Read or Write completely
separate data objects, they do not conflict.
•  If 1 transaction Writes a data object and another
either Reads or Writes the same data objects
 Anomalies with interleaved execution
• Two actions on the same data object conflict if
at least one of them is a write
• We’ll now consider three ways in which a
schedule involving two consistency-preserving
transactions can leave a consistent database
inconsistent

23