Transaction Processing

What is a Transaction?

• A transaction is an event which occurs on the database. Generally a

transaction reads a value from the database or writes a value to the database.
• Sequence of different set of actions constitutes to be single atomic unit of
work.
• Operations on transactions
– Read, write
– combination of SELECT, UPDATE, and INSERT statements
– Special actions: commit, abort,rollback
Eg
Begin_Transaction
Read EmpNo, Salary
Salary = Salary * 1.15
Write EmpNo, Salary
Commit
 Transaction Concept
• 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)

• Two main issues to deal with:

– Failures of various kinds, such as hardware failures
and system crashes
– Concurrent execution of multiple transactions
•
Example of Fund Transfer
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)
• Atomicity requirement
– If the transaction fails after step 3 and before step 6, money will be “lost” leading to
an inconsistent database state
• Failure could be due to software or hardware
– The system should ensure that updates of a partially executed transaction are not
reflected in the database
• Durability requirement — once the user has been notified that the transaction has
completed (i.e., the transfer of the $50 has taken place), the updates to the database by
the transaction must persist even if there are software or hardware failures.
•
Example of Fund Transfer (Cont.)
Consistency requirement in above example:
– The sum of A and B is unchanged by the execution of the transaction
• In general, consistency requirements include
– Explicitly specified integrity constraints such as primary keys and foreign keys
– Implicit integrity constraints
• e.g., sum of balances of all accounts, minus sum of loan amounts must equal
value of cash-in-hand
– A transaction must see a consistent database.
– During transaction execution the database may be temporarily inconsistent.
– When the transaction completes successfully the database must be consistent
• Erroneous transaction logic can lead to inconsistency
Example of Fund Transfer (Cont.)
• Isolation requirement — if between steps 3 and 6,
another transaction T2 is allowed to access the partially
updated database, it will see an inconsistent database (the
sum A + B will be less than it should be).

T1 T2
1. read(A)
2. A := A – 50
3. write(A)
read(A), read(B), print(A+B)
4. read(B)
5. B := B + 50
6. write(B

• Isolation can be ensured trivially by running transactions

serially
– That is, one after the other.
• However, executing multiple transactions concurrently has
significant benefits, as we will see later.
 Why Concurrency Control Is Needed
• The Lost Update Problem. This problem occurs when two transactions that
access the same database items have their operations interleaved in a way that
makes the value of some database items incorrect. Suppose that transactions T1
and T2 are submitted at approximately the same time, and suppose that their
operations are interleaved as shown in Figure then the final value of item X is
incorrect because T2 reads the value of X before T1 changes it in the database,
and hence the updated value resulting from T1 is lost. For example, if X = 80 at the
start (originally there were 80 reservations on the flight),N = 5 (T1 transfers 5 seat
reservations from the flight corresponding to X to the flight corresponding to Y),
and M = 4 (T2 reserves 4 seats on X), the final result should be X = 79.However, in
the interleaving of operations shown in Figure it is X = 84 because the update in
T1 that removed the five seats from X was lost.
 Why Concurrency Control Is Needed
• The Temporary Update (or Dirty Read) Problem. This problem occurs when
one transaction updates a database item and then the transaction fails for some
reason (see Section 21.1.4).Meanwhile, the updated item is accessed (read) by
another transaction before it is changed back to its original value. Figure 21.3(b)
shows an example where T1 updates item X and then fails before completion, so
the system must change X back to its original value. Before it can do so, however,
transaction T2 reads the temporary value of X, which will not be recorded
permanently in the database because of the failure of T1. The value of item X that
is read by T2 is called dirty data because it has been created by a transaction that
has not completed and committed yet; hence, this problem is also known as the
dirty read problem.
 Why Concurrency Control Is Needed
• The Incorrect Summary Problem. If one transaction is calculating an aggregate
summary function on a number of database items while other
transactions are updating some of these items, the aggregate function
may calculate some values before they are updated and others after they
are updated. For example, suppose that a transaction T3 is calculating the
total number of reservations on all the flights; meanwhile, transaction T1
is executing. If the interleaving of operations shown in Figure 21.3(c)
occurs, the result of T3 will be off by an amount N because T3 reads the
value of X after N seats have been subtracted from it but reads the value
of Y before those N seats have been added to it.
 ACID Properties
A transaction is a unit of program execution that accesses and
possibly updates various data items. To preserve the integrity of
data the database system must ensure:
• Atomicity. Either all operations of the transaction are properly
reflected in the database or none are.
• Consistency. Execution of a transaction in isolation preserves the
consistency of the database.
• Isolation. Although multiple transactions may execute concurrently,
each transaction must be unaware of other concurrently executing
transactions. Intermediate transaction results must be hidden from
other concurrently executed transactions.
– That is, for every pair of transactions Ti and Tj, it appears to Ti that either Tj,
finished execution before Ti started, or Tj started execution after Ti finished.
• Durability. After a transaction completes successfully, the changes it
has made to the database persist, even if there are system failures.
 ACID Properties
• Every transaction, for whatever purpose it is being used, has the following
four properties. Taking the initial letters of these four properties we
collectively call them the ACID Properties. Here we try to describe them
and explain them.
– Atomicity
– Consistency
– Isolation
– Durability
 ACID Properties
Atomic – All or Nothing
This means that either all of the instructions within the transaction will be
reflected in the database, or none of them will be reflected.
• It is necessary to make sure that either all actions of a transaction are
completed or the transaction has no effect on the database.Therefore a
transaction is either completed successfully or rolled back. This is sometime
called all-or-nothing property
• Say for example, we have two accounts A and B, each containing Rs 1000/-.
We now start a transaction to deposit Rs 100/- from account A to Account B.
Read A;
A = A – 100;
Write A;
Read B;
B = B + 100;
Write B;
 ACID Properties
Consistent
Each user is responsible to ensure that their transaction (if executed by
itself) would leave the database in a consistent state

Consistency: If we execute a particular transaction in isolation or together

with other transaction, (i.e. presumably in a multi-programming
environment), the transaction will yield the same expected result
• For example if a person withdraws Rs 100 from the ATM the person’s
account is balanced before the withdrawal (transaction). After the
withdrawal the account must also be balanced.
 ACID Properties
Isolation
The final effects of multiple simultaneous transactions must be the same as
if they were executed one right after the other.
• No other transactions should view any partial results of the actions of a
transaction since intermediate states may violate consistency. Each
transaction must be executed as if it was the only transaction being
carried out.
Durability
If a transaction has been committed, the DBMS must ensure that its effects
are permanently recorded in the database (even if the system crashes).
A committed transaction cannot be aborted.
 Transaction State
• Active – the initial state; the transaction stays in this state
while it is executing
• Partially committed – after the final statement has been
executed.
• Failed -- after the discovery that normal execution can no
longer proceed.
• Aborted – after the transaction has been rolled back and
the database restored to its state prior to the start of the
transaction. Two options after it has been aborted:
– Restart the transaction
• Can be done only if no internal logical error
– Kill the transaction
• Committed – after successful completion.
Transaction State (Cont.)
 Transaction States

• Committed: If no failure occurs then the transaction reaches the

COMMIT POINT. All the temporary values are written to the stable
storage and the transaction is said to have been committed.
• Terminated: Either committed or aborted, the transaction finally reaches
this state.
 Concurrent Executions
• Multiple transactions are allowed to run concurrently
in the system. Advantages are:
– Increased processor and disk utilization, leading to better
transaction throughput
• E.g., one transaction can be using the CPU while another is
reading from or writing to the disk
– Reduced average response time for transactions: short
transactions need not wait behind long ones.
• Concurrency control schemes – mechanisms to
achieve isolation
– That is, to control the interaction among the concurrent
transactions in order to prevent them from destroying the
consistency of the database
• Will study in Chapter 15, after studying notion of correctness of
concurrent executions.
 Schedules
• Schedule – a sequences of instructions that specify the
chronological order in which instructions of concurrent
transactions are executed
– 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.
• 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
 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 :
 Schedule 2
• A serial schedule where T2 is followed by T1
 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.

 Schedule 4
• The following concurrent schedule does not preserve the value of (A + B ).
 Serializability
• When several concurrent transactions are trying to access the same data
item, the instructions within these concurrent transactions must be ordered
in some way so as there are no problem in accessing and releasing the
shared data item. There are three aspects of serializability which are
described here:

• If 2 Transactions are only reading data items – They do not conflict 

Order is unimportant
• If 2 Transactions operate (Read/Write) on Separate Data Items
– They do not conflict  Order is unimportant
• If 1 Transaction Writes to a Data Item and Another Reads or Writes to the
Same Data Item  The Order of Execution IS Important
 Locking
• Lock guarantees exclusive use of data item to current transaction
• Prevents reading Inconsistent Data
• Lock Manager is responsible for assigning and policing the locks used by
the transaction
 Locking Granularity
Indicates the level of lock use
• Database Level – Entire Database is Locked
• Table Level – Entire Table is Locked
• Page Level – Locks an Entire Disk page
(Most Frequently Used)
• Row Level – Locks Single Row of Table
• Field Level – Locks a Single Attribute of a Single Row (Rarely Done)
 Types of Locks: Binary
• Binary Locks – Lock with 2 States
– Locked – No other transaction can use that object
– Unlocked – Any transaction can lock and use object

All Transactions require a Lock and Unlock Operation

for Each
Object Accessed (Handled by DBMS)
– Eliminates Lost Updates
– Too Restrictive to Yield Optimal Concurrency
Conditions
 Types of Locks:
Shared / Exclusive Locks

• Indicates the Nature of the Lock

• Shared Lock – Concurrent Transactions are granted READ access on the
basis of a common lock.
• Exclusive Lock – Access is reserved for the transaction that locked the
object.
• 3 States: Unlocked, Shared (Read), Exclusive (Write)
• More Efficient Data Access Solution
• More Overhead for Lock Manager
– Type of lock needed must be known
– 3 Operations:
• Read_Lock – Check to see the type of lock
• Write_Lock – Issue a Lock
• Unlock – Release a Lock
– Allow Upgrading / Downgrading of Locks
 Time Stamping
Creates a specific order in which the transactions are processed by the DBMS
2 Main Properties
1. Uniqueness – Assumes that no equal time stamp
value can exist (ensures serializability of the
transactions)
2. Monotonicity – Ensures that time stamp values
always increases
All operations within the same transaction have the same time stamp
If Transactions conflict, one is rolled back and rescheduled
Each value in Database requires 2 Additional Fields: Last Time Read / Last
Time Updated
Increases Memory Need and Processing Overhead
 Time Stamping Schemes
• Wait / Die Scheme
The older transaction will wait
The younger transaction will be rolled back

Example; Suppose, there are two transactions T1 and T2 and Let timestamp of any
transaction T be TS (T).
• Now, If there is a lock on T2 by some other transaction and T1 is requesting for
resources held by T2, then DBMS performs following actions:

• Checks if TS (T1) < TS (T2)

• – if T1 is the older transaction and T2 has held some resource, then it allows T1
to wait until resource is available for execution.
• That means if a younger transaction has locked some resource and older
transaction is waiting for it, then older transaction is allowed wait for it till it is
available.
• If T1 is older transaction and has held some resource with it and if T2 is waiting
for it, then T2 is killed and restarted latter with random delay but with the same
timestamp. i.e. if the older transaction has held some resource and younger
transaction waits for the resource, then younger transaction is killed and
restarted with very minute delay with same timestamp.
 Optimistic Method
• Most database operations do not conflict
• No locking or time stamping
• Transactions execute until commit
– Read Phase – Read database, execute
computations, make local updates (temporary
update file)
– Validate Phase – Transaction is validated to ensure
changes will not effect integrity of database
• If Validated  Go to Write Phase
• If Not Validated  Restart Transaction and discard
initial changes
– Write Phase – Commit Changes to database
• Good for Read / Query Databases (Few Updates)