Transaction Management

TRANSACTION

◼ Its smallest unit of program execution that accesses

& possibly updates various data items.
◼ Set of changes that must be made together.
(executed as single unit.)
◼ Its program unit that may or may not change
contents of database.
◼ Eg;
❑ Transfer of money from one account to another; viewed as
transaction with set of two steps:
◼ Debiting money from one bank account
◼ Crediting money to another bank account.
 Transaction Properties

◼ A-Atomicity:
❑ All or nothing approach
◼ C-Consistency
❑ Change in one is reflected to another table of DB
◼ I-Isolation
❑ Several transactions are carried out concurrently
◼ D-Durability
❑ Completed or committed transactions should
persist even after Crash or Failures.
 Transaction States
◼ Active:
❑ Initial state & stays there during execution.
◼ Partially Committed
❑ When executed the final statement.
◼ Failed
❑ Cannot execute
transaction normally.
◼ Aborted
❑ Database rolled back
to prior state after failure.
After this we can either:
◼ Kill transaction
◼ Restart transaction
◼ Committed:
❑ After successful
completion.
 Transaction Operations

◼ READ(X):
❑ Transfers data item ‘X’ from database to local
buffer of transaction.
◼ WRITE(X):
❑ Transfers data item ‘X’ from local buffer of
transaction to be written in database.
 Transaction Log
◼ DBMS uses transaction log to keep track of all updates done to
database.
◼ Information stored there is used for recovery during
❑ ROLLBACK statement, Abnormal termination & System failure.
◼ It stores records of:
❑ Beginning of transaction.
❑ For each transaction:
◼ Type of operation being performed
◼ Name of objects affected by transaction
◼ “before” & “after” values for fields being updated
◼ Pointers to previous & next transaction log entries.
❑ Ending of transaction.
Tri_id Trx_no Prev Next Operation Table Row id Attribute Before After
Ptr Ptr Value Value
341 101 Null 352 START *** Start
Transaction
352 101 341 365 UPDATE PRODUCT 1558- PROD- 25 23
QWI QOH
365 101 352 Null COMMIT *** End
Transaction
 Transaction Schedule
◼ “SCHEDULE”
❑ is a list of actions (reading, writing, aborting or committing)
from set of transactions,
❑ which consist of all instructions of those transactions, &
❑ Must preserve order in which instructions appear in these
individual transactions.
◼ It represents an actual execution sequence.
◼ Transaction schedule can be:
❑ Compete Schedule
❑ Serial Schedule
❑ Non-Serial Schedule
❑ Equivalent Schedule
❑ Serializiable Schedule
 Complete Schedule

◼ A schedule that contains either an abort or a

commit for each transaction whose actions are
listed in it.
 Serial Schedule
T1 T2
◼ Consist of sequence of Read (A);
instructions from various A:=A-50;
transactions, where Write (A);
instructions belonging to Read (B);
one single transaction B:=B+50;
Write (B);
appear together in that
Read (A);
schedule. Temp:=A*0.1;
A:=A-temp;
Write (A);
Read (B);
B:=B+temp;
Write (B);
 Equivalent Schedule
◼ When the T1 T2 T1 T2
Read (A); Read (A);
execution of A:=A-50; Temp:=A*0.1;
first schedule Write (A); A:=A-temp;
Read (B); Write (A);
have same
B:=B+50; Read (B);
effect as of Write (B); B:=B+temp;
second schedule. Read (A); Write (B);
Temp:=A*0.1; Read (A);
A:=A-temp; A:=A-50;
Write (A); Write (A);
Read (B); Read (B);
B:=B+temp; B:=B+50;
Write (B); Write (B);
 Non-Serial Schedule
T1 T2
◼ Schedule in which
Read (A);
instructions from set of
A:=A-50;
concurrent transactions Write (A);
are interleaved together. Read (A);
◼ With multiple transactions, Temp:=A*0.1
A:=A-temp;
CPU time is shared
Write (A);
among all the Read (B);
transactions. B:=B+50;
Write (B);
Read (B);
B:=B+temp;
Write (B);
 Serializiable Schedule
T1 T2 T1 T2
◼ Serializiable Read (A); Read (A);
schedule A:=A-50; A:=A-50;
Write (A); Write (A);
is a non-serial
Read (B); Read (A);
schedule B:=B+50; Temp:=A*0.1
which is Write (B); A:=A-temp;
Read (A); Write (A);
equivalent to Temp:=A*0.1; Read (B);
some serial A:=A-temp; B:=B+50;
Write (A); Write (B);
schedule.
Read (B); Read (B);
B:=B+temp; B:=B+temp;
Write (B); Write (B);
 Serializiability
◼ Process of finding non-serial schedule that
allow transactions to execute concurrently
without interfacing with one another &
produce a database that could be produced
by a serial schedule.