Advanced Database Systems

Chapter-II
Transaction Processing and Concurrency Control

Basics of Database Transactions

Transaction processing involves the operating side of databases. Whereas
operations management describes how physical goods are produced, transaction
management describes how information of goods or transactions is controlled.
Transaction management, like management of physical goods is enormously
important to modern organization. Organization such as banks with automatic
tellers, airlines with on-line reservation and universities with on-line registration
could not function without reliable and efficient transaction processing. In common
discourse, a transaction is a interaction among two or more for the conduct of
business such as buying a car from a dealership. Transactions for DBMSs have a
more precise meaning. A database transaction involves a collection of operations
that must be processed as one unit of work. Transactions should be processes
reliably so that there is no loss of data due to multiple users and system failures. To
help you grasp this more precise meaning, this section presents examples of
transactions and defines properties of transactions.

Transaction Examples
A transaction is a user-defined concept. For example, making an airline reservation
may involve reservations for the departure and return. To the user, the combination
of the departure and the return is a transaction, not the departure and the return
separately. Most travelers do not want to depart without returning. The implication
for DBMSs is that a transaction is a user-defined set of database operations. A
transaction can involve any number of reads and writes to a database. To provide
the flexibility of user-defined transactions, DBMSs cannot restrict transactions to
only a specified number of reads and writes to a database.
An information system may have many different kinds of transactions. The
following table depicts transactions of an order entry system.

Transaction Kind Description

Add order Customer places a new order
Update order Customer changes details of an existing order
Check status Clerk reports the status of an order to customer
Payment Payment received from customer
Shipment Goods sent to customer
Table: Typical Transactions in an Order Entry System

SQL Statements to Define Transactions

To define transaction, we can use some additional statements. The figure depicts
additional SQL statements to define the prototypical automatic teller machine
(ATM) transaction. The BEGIN TRANSACTION and COMMIT statements define
the statements in the transaction. Any other SQL statements between them are part

Samuel Giftson, Dept of Computing, COE, MU 1

 of the transaction. Typically, a transaction involves a number of SELECT,
UPDATE, INSERT, DELETE statements.

BEGIN TRANSACTION
Display greeting
Get account number, pin, type, and amount
SELECT account number, type, and balance
If balance is sufficient then
UPDATE account by posting debit
UPDATE account by posting credit
INSERT history record
Display final message and issue cash
Else
Write error message
End If
On Error: ROLLBACK
COMMIT

Besides the BEGIN TRANSACTION and COMMIT statements, the ROLLBACK

statement may be used. It is like an undo command in a word processor.
ROLLBACK causes all effects of a transaction to be removed. The database
restored to the state before the transaction was executed. One situation for issuing a
ROLLBACK statement is to allow the user to cancel a transaction. It can also be
used as a part of exception handling statements such as the “On-Error”.

Transaction Properties
DBMSs ensure that transactions obey certain properties. The most important
properties are ACID properties (Atomic, Consistent, Isolated and Durable).
Atomic means that a transaction can’t be subdivided. Either all the work in the
transaction is completed or nothing is done. For example, the ATM transaction will
not debit an account without also crediting a corresponding account.
Consistent means that if applicable constraints are true before the transaction starts, the
constraints will be true after the transaction terminates. For example, if a users
account is balanced before a transaction, then the account is balanced after the
transaction. Otherwise, the transaction is rejected and no changes take effect.
Isolated means that changes resulting from a transaction are not revealed to other users
until the transaction terminates. For example, your significant other will not know
that you are withdrawing money until your ATM transaction completes.
Durable means that any changes resulting from a transaction are permanent. No failure
will erase any changes after a transaction terminates. For example, if a banks
computer experiences a failure seconds after your transaction completes the result
of your transaction are still recorded on the bank database.
To ensure that, transactions meet the ACID properties, DBMSs provide certain
services that are transparent to database developers and programmers. The DBMSs

Samuel Giftson, Dept of Computing, COE, MU 2

transparency means that the inner details of the transaction services are invisible.
Transparency is important because services that ensure ACID transactions are very
difficult to implement. DBMS provide two services, recovery transparency and
concurrency transparency to ensure that transactions obey the ACID properties.
Recovery transparency means that the DBMS automatically restores a database to a
consistent state after a failure. For example if a communication failure occurs
during an ATM transaction, the effects of the transaction are automatically
removed from the database. On the other hand, if the DBMS crash three seconds
after an ATM transaction is completed, the effects of the transaction are still
remaining on the database.
Concurrency Transparency means that users perceive the database as a single user
system even though there may be many simultaneous users. For example, even
though many users may try to reserve a popular flight using a reservation
transaction, the DBMS ensures that users do not overwrite each other’s work.
Even though the inner details of concurrency and recovery are not visible to a user, these
services are not free. Recovery and concurrency involve overhead that may
adversely impact performance or require additional resources to reach an
acceptable level of performance. The database designers must be aware of the
resource implications of these services.

Transaction State
In the absence of failure, all transactions complete successfully. However, as we noted
earlier, a transaction may not always complete its execution successfully. Such a
transaction is termed aborted. If we are to ensure the atomicity property, an aborted
transaction must have no effect on the state of the database. Thus, any changes that
the aborted transaction made to the database must be undone. Once the changes
caused by an aborted transaction have been undone, we say that the transaction has
been rolled back. It is the part of the recovery scheme to manage transaction aborts.

A transaction that completes its execution successfully is said to be committed. A

committed transaction that has performed updates transforms the database into a new
consistent state, which must persist even if there is a system failure.

Once a transaction has committed, we cannot undo its effects by aborting it. The
only way to undo the effects of a committed transaction is to execute a
compensation transaction. For Ex: if a transaction added 100$ to an account, the
compensation transaction would subtract 100$ from the account. However, it is not
always to create such a compensation transaction. Therefore, the responsibility of
writing and executing a compensation transaction is left to the user and it is not
handled by the database system.
A transaction must be in one of the following states:
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 has been restored to
its state prior to the start of the transaction.

Samuel Giftson, Dept of Computing, COE, MU 3

Committed: After Successful Completion.

The state diagram for the above states

Part. Committe
Committed
d

Active

Aborte
Failed d

A transaction is committed only if it has entered the committed state. Similarly, a

transaction has aborted only if it has entered the aborted state. A transaction is said to
have terminated if has either committed or aborted.
A transaction starts in the active state. When it finishes its final statement, it enters the
partially committed state. At this point the transaction has completed its execution,
but it is still possible that it may have to be aborted, since actual output may still be
temporarily residing in main memory and thus a hardware failure may preclude its
successful completion.
The database system then writes out enough information to disk that, even in the
event of a failure, the updates performed by the transaction can be re-created when the
system restarts after the failure. When the last of this information is written out, the
transaction enters the committed state.
A transaction enters the failed state after the system determines that the
transaction can no longer proceed with its normal execution (because of hardware or
logical errors). Such a transaction must be rolled back. Then, it enters the aborted state.
At this point, the system has two options:
It can restart the transaction, but only if the transaction was aborted as a result of some
hardware or software error that was not created through the internal logic of the
transaction. A restarted transaction is considered to be a new transaction.
It can kill the transaction. It usually does so because of some internal logical error that
can be corrected only by rewriting the application program, or because the input
was bad, or because the desired data were no found in the database.

Concurrency Control

Samuel Giftson, Dept of Computing, COE, MU 4

 Most organizations cannot function without multi-user databases. For example,
airline, banking can have thousands of users simultaneously trying to conduct
business. Multiple users can access these databases concurrently, that is at the same
time. However, concurrent user cannot be permitted to interfere with each other.
Objective of Concurrency Control
The objective of the concurrency control is to maximize transaction throughput
while preventing interference among multiple users. Transaction throughput, the
number of transactions processed per unit time, is a measure of the amount of work
performed by a DBMS. Typically, transaction throughput is reported in
transactions per minute. From the perspective of the user, transaction throughput is
related to the response time. High transaction throughput means lower response
time. If there is no interference, the result of executing concurrent transactions is
the same as executing the same transactions in some sequential order. Executing
transactions sequentially would result in a low throughput and high waiting times.
Thus, DBMS allowed transaction to execute simultaneously while ensuring the
result are same as though executed sequentially. Transaction executing
simultaneously cannot interfere unless they’re manipulating common data. Most
concurrent transactions manipulate only small amount of common data. A hotspot
is common data that multiple users try to change simultaneously. A hotspot
represents a resource that the users must queue to access. Typically, hotspot are the
seats remaining for popular flights the quantity on hand of popular inventory items
etc. interference on hotspots can lead to last data and poor decision making. The
following section describes interference problems and tools to prevent them.

Interference problems
There are three problems that can result because of simultaneous access to the
database:
Lost update
Uncommitted dependency
Incorrect summary

1. Lost Update
This is the most serious interference problem because changes to databases are
inadvertently lost. In a lost update, one users update overwrites another user update,
which is depicted by the time line as below:

Transaction A Time Transaction B

Read SR(10) T1
T2 Read SR(10)
If SR > 0 then SR = SR-1 T3
T4 If SR > 0 then SR = SR-1
Write SR(9) T5
T6 Write SR(9)

Samuel Giftson, Dept of Computing, COE, MU 5

 Figure: Example Lost Update Problem

The timeline shows two concurrent transactions trying to update the seats remaining (SR)
field of the same flight record. Assume that the value of SR is 10 before the
transaction begin. After time T2 both transactions have stored the value of 10 for
SR in local buffers. After time T4 both transactions have made changes to their
local copy of SR. however, each transaction changes the value to 9, unaware the
activity of the other transaction. After time T6, the value of SR on the database is 9.
But the value after finishing both transactions should be 8 not 9, one of the changes
has been lost. Some students become confused about the lost update problem
because of the actions performed on local copies of the data. The calculations at
times T3 and T4 are performed in memory buffers specific to each transaction.
Even though transaction A has changed the value of SR, transaction B performs the
calculation with its own local copy of SR having a value of 10. The write operation
performed by transaction A is not known to transaction B unless transaction B
reads the value again. A lost update involves two or more transactions trying to
change the same part of the database.

2. Uncommitted Dependency
It occurs when one transaction reads data written by another transaction before
other transaction commits. It is also known as dirty read because it is caused by one
transaction reading dirty data. In the figure, transaction A reads the SR fields,
changes its local copy of the SR field, and writes the new value back to the
database. Transaction B then reads the changed value. Before transaction A
commits, however an error is detected and transaction A issues a rollback. The
rollback could have been issued as a result of the user canceling the transaction or a
result of failure. The value used by B is wrong. The
Transaction A Time Transaction B

Read SR(10) T1
SR = SR-1 T2
Write SR(9) T3
T4 Read SR(9)
Rollback T5

Figure: Example dirty read Problem

real SR value is now 10 because A changes was not permanent. An uncommitted

dependency involves one transaction writing and another transaction reading the
same part of the database.

Samuel Giftson, Dept of Computing, COE, MU 6

3. Incorrect Summary
The third problem, the incorrect summary is the least serious of the interference
problems. It occurs when a transaction calculating a summary function reads some
values before another transaction changes the value but reads other values after
another transaction changes the values. In figure, transaction B reads SR1 after
transaction A changes the value but reads SR2 before transaction A changes the
value. For consistency, transaction B should use all the values either before or after
they are changed by another transaction. An incorrect summary involves one
transaction reading and the second transaction changing the same part of the
database.

Transaction A Time Transaction B

Read SR1(10) T1
SR1 = SR1-1 T2
Write SR1(9) T3
T4 Read SR1(9)
T5 Sum=Sum+SR1
T6 Read SR2(5)
T7 Sum=Sum+SR2
Read SR2(5) T8
SR2=SR2-1 T9
Write SR2(4) T10

Figure: Example Incorrect Summary Problem

Concurrency Control Tools

This section describes two tools used by most DBMSs to prevent the three
interference problem discussed above. The tools are
Locks
Two-Phase locking protocol

Locks
Locks provide a way to prevent other users from accessing part of the database
being used. Before accessing part of the database, a lock must be obtained. Other
users must wait if trying to obtain conflicting lock on the same part of the database.
Following table shows conflicts for two kinds of locks.

Samuel Giftson, Dept of Computing, COE, MU 7

 User 2 Requests
S Lock X Lock
User 1 Holds
S Lock Lock Granted User 2 waits
X Lock User 2 waits User 2 waits
Table: Locking Conflicts

A shared lock (S) must be obtained before reading the database, while an exclusive locks
(X) must be obtained before writing. As shown in the above table, any number of
users can hold a shared lock on the same part of the database whereas only one user
can hold an exclusive lock.
The concurrency control manager is the part of the DBMS responsible for
managing locks. The concurrency control manager maintains a hidden table to
record locks held by various transactions. A lock record contains a transaction
identifier, a record identifier, a kind, and a count, as explained in the following
table

Field Name Description

Transaction Identifier Unique identifier for transaction
Record Identifier Identifies the record to be locked
Kind Indicates the intended usage of the locked record
Count Number of other user holding this kind of lock
Table: Fields in a Lock Record
In the simplest scheme, the kind is either shared or exclusive, as discussed
previously. Most DBMSs have other kinds of locks to improve efficiency and allow for
more concurrent access. The concurrency control manager can perform two actions on
lock records. The lock action adds a record to the lock table. Likewise, the unlock or
release action deletes a record from the lock table.
Locking granularity is one complication about locks. Granularity refers to the size
of the database item locked. The previous discussion assumed that locks are held
for records. Most DBMSs can hold locks for different granularities, as depicted in
the following figure. Database

Table Index

Page

Record

Field

Samuel Giftson, Dept of Computing, COE, MU 8

 Figure: Typical Levels of Locking Granularity

The entire database is the coarsest lock that can be held. If an exclusive lock is held on
the entire database, no other users can access the database until the lock is released.
On the other extreme, an individual field is the finest lock that can be held. Locks
also can be held on parts of the database not generally seen by users. For example,
locks can be held on indexes and pages (physical records).
Locking granularity is a trade-off between overhead and waiting. Holding locks at a
fine level decreases waiting among users but increases system overhead because
more locks must be obtained. Holding locks at a coarser level reduces the number
of locks but increases the amount of waiting. In some DBMSs, the concurrency
control manages to detect the pattern of usage and promotes locks if needed. For
example, the concurrency control manager initially can grant record locks to a
transaction in anticipation that only a few records will be locked. If the transaction
continues to request locks, the concurrency control component can promote the
record locks to a lock on the entire table.

Deadlocks
Using locks to prevent interference problems can lead to deadlocks. A deadlock is a
problem of mutual waiting. One transaction has a resource that another transaction
needs, and a second transaction holds a resource that the first transaction needs.
Figure depicts a deadlock among two transactions trying to reserve seats on a flight
involving more than one part.

Transaction A Time Transaction B

XLock SR1 T1
T2 XLock SR2
XLock SR2 (wait) T3
T4 XLock SR1 (wait)
SR(9) Figure: Example
T5 deadlock ProblemSum=Sum+SR1

Transaction A acquires an exclusive lock on the first part followed by transaction

B acquiring a lock on the second part. Transaction A tries to lock the second part but is
blocked because transaction B holds an exclusive lock. Likewise, transaction B must wait
to obtain a lock on the first part. Deadlocks can involve more than two transactions. But
the pattern is more complex. The concurrency control manager can either prevent
deadlocks or detect deadlocks. To prevent deadlocks the concurrency control manager
aborts transactions. Most DBMSs use a time out policy to select transactions to abort.
The concurrency control manager aborts with a rollback statement any transaction
waiting for more than a specified time. Some DBMS try to detect deadlock by looking for
patterns of mutual waiting. Because detecting deadlocks can involve significant
computation time, most DBMSs do not try to detect them.

Samuel Giftson, Dept of Computing, COE, MU 9

Two phase Locking Protocol
To ensure that lost update problems do not occur, the concurrency control manager
requires that all transactions follow the two-phase locking protocol (2PL). for
concurrency control all the transaction must follow the 2PL protocol to ensure that
no interference problems occur. Two-phase locking has two conditions:
Before reading or writing to a part of the database. The transaction must acquire the
applicable lock to that part of database.
After releasing a lock, the transaction doesn’t acquire any new locks.

The first condition follows from the usage of locks as explained previously. The second
condition, if new locks are acquired after releasing locks, a group of transaction can
operate on different states of a data item, leading to lost update problems. The
second condition is usually simplified so that at least exclusive locks are held until
the end of the transactions. At the commit points, locks of a transaction are
released. The figure shows the 2PL with simplified second condition.
Locks Held

Growing Phase

Shrinking Phase

BOT EOT
Time

Figure: Growing and Shrinking Phases of 2PL

At the beginning of transaction (BOT), a transaction has no locks. A growing phase

ensures in which transaction acquires locks but never release any locks. At the end
of transaction (EOT), the shrinking phase in which all locks are released together.
Simplifying the definition of 2PL makes the protocol easier to enforce and prevents
other concurrency control problems.

Optimistic Approaches
The use of locks and 2PL is a pessimistic approach to concurrency control. Locking
assumes that every transaction conflicts. Optimistic concurrency control
approaches assumes that conflicts are rare. If conflicts are rare it is more efficient to
check for conflicts rather than use of locks to force waiting. In this transactions are
permitted to access the database without acquiring locks. Instead, the concurrency
control manager checks whether a conflicts has occurred. The check can be

Samuel Giftson, Dept of Computing, COE, MU 10

 performed either just before a transaction commits or after each read and write. If
conflicts occur, the concurrency control manager issues a rollback and restarts the
offending transaction. The performance of optimistic approaches depends on the
frequency of the conflicts. If conflicts increase, the performance of optimistic
approaches decreases. Optimistic approaches resolve conflicts by rollback and
restarting.

Recovery Management
Recovery management is a service to restore a database to a consistent state after a
failure. This section describes the kinds of failures to prevent, the tools of recovery
management, and the recovery processes that use the tools.
Data Storage Devices and Failure Types
From the perspective of database failures, volatility is an important characteristic of
data storage devices. Main memory is volatile because it loses its state if power is
lost. In contrast, a hard disk is nonvolatile because it retains its state if power is
lost. This distinction is important because DBMSs cannot depend on volatile
memory to recover data after failures. Even nonvolatile devices are not completely
reliable. For example, certain failures make the contents of a hard disk unreadable.
To achieve high reliability, DBMSs may replicate data on several kinds of
nonvolatile storage media such as hard disk, magnetic tape, and an optical disk.
Using a combination of non-volatile devices improves reliability because different
kinds of devices usually have independent failure rates.
Some failures affect main memory only, while others affect both volatile and non-
volatile memory. The following table shows four kinds of failures along with their
effect and frequency. The first two kinds of failures affect memory of one
executing transaction.

Type Effect Frequency

Program-detected Local (1 transaction) Most frequent
Abnormal termination Local (1 transaction) Moderate frequency
System failure Global (all active transactions) Not frequent
Device failure Global (all active and past Least frequent
transactions)
Table: Failure Types, Effects, and Frequency

When writing code, one often checks for error conditions such as invalid account number
or cancellation of the transaction by the user. A program-detected failure usually
leads to aborting the transaction with the specified message to the user. The SQL
ROLL BACK statement is used to abort a transaction if an abnormal condition
occurs. Recall that the ROLL BACK statement causes all changes made by the
transaction to be removed from the database. Program-detected failures are usually
the most common and least harmful.
Abnormal termination has an effect similar to a program-detected failure but a
different cause. The transaction aborts, but the error message is unintelligible to the

Samuel Giftson, Dept of Computing, COE, MU 11

 user. Abnormal termination can be caused by events such as transaction time-out,
communication line failure, or programming error (for example, dividing by zero).
The last two kinds of failures have more serious consequences but are usually far
less common. A system failure is an abnormal termination of the operating system.
An operating system failure affects all executing transactions. A device failure such
as a disk crash affects all executing transactions and all committed transactions
whose work is recorded on the disk. A device failure can take hours to recover
while a system crash can take minutes.

Recovery Tools
The recovery manager uses redundancy and control of the timing of database writes
to restore a database after a failure. Three tools discussed in this section-transaction
log, check point, and database backup-are forms of redundancy. The last tool-force
writing-allows the recovery manager to control when database writes are recorded.

Transaction Log
It a like a shadow following a database. Any change to the database is also recorded
in the log. A typical log (following table) contains a transaction identifier, the
database action, the time, a row identifier, a column name, and values (odd and
new). The old and new values are sometimes called the before and after images,
respectively. If the database action is insert, the log only contains the new value.
Similarly, if the database action is delete, the log only contains the old value.
Besides insert, update, and delete actions, log records are created for the begin and
the end of the transaction. The log is usually stored as a hidden database table not
available to normal users.

Trans Action Time Table Row Column Old New

N
o
.
T101 BEGIN 10:29
T101 Update 10:30 Acct A10 Bal 100 200
T101 Update 10:30 Acct A25 Bal 500 400
T101 Insert 10:32 Hist H100 CustNo C100
T101 End 10:33
Table: Example Transaction log for an ATM Transaction

The recovery manager can perform two operations on the log. In an undo operation,
the database reverts to a previous state by substituting the old value for whatever
value is stored in the database. In a redo operation, the recovery component
reestablishes a new state by substituting the new value for whatever value is stored
in the database. To undo (redo) a transaction, the undo (redo) operation is applied
to all log records of a specified transaction except for the begin and commit
records.

Samuel Giftson, Dept of Computing, COE, MU 12

Checkpoint Table
The checkpoint table is another hidden table used by the recovery manager. The
purpose of the checkpoint table is to reduce the time to recover from failures. At
periodic times, a record is written to the checkpoint table to record the current log
position. In addition, a checkpoint record is added to the log to record all active
transactions and all log buffers are written to disk. At start time, the recovery
manager consults the checkpoint table to commence the restoration process.
The checkpoint interval is defined as the period between writing to the checkpoint
table. The interval can be expressed as a time (such as five minutes) or as a number
of committed transactions. The checkpoint interval is a design parameter. A small
interval reduces restart work but causes more overhead to record checkpoints. A
large interval reduces checkpoint overhead but increases restart work. A typical
checkpoint interval might be five minutes for large transaction volumes.
The implementation of the checkpoint process depends on the DBMS. In most
DBMSs, all transaction activity must cease while a checkpoint occurs. Other
systems permit concurrent transaction processing while a checkpoint occurs. The
checkpoint interval should be larger (less frequent) if the DBMS requires all
transaction activity to cease until a checkpoint completes.

Force Writing
The ability to control when data are transferred to nonvolatile storage is known as
force writing. Without the ability to control the timing of write operations to
nonvolatile storage, recovery is not possible. Force writing means that the DBMS,
not the operating system, controls when data are written to nonvolatile storage.
Normally, when a program issues a write command, the operating system puts the
data in a buffer. For efficiency, the data are not written to disk until the buffer is
full. Typically, there is some small delay between the arrival of data in a buffer and
the transferring of the buffer to disk. With force writing, the operating system
allows the DBMS to transfer the data directly to disk without the intermediate use
of the buffer.
The recovery manager uses force writing at checkpoint time and the end of the
transaction. At checkpoint time, in addition to inserting a checkpoint record, all log
and sometimes all database buffers are force written to disk. This force writing can
add considerable overhead to the checkpoint process. At the end of the transaction,
the recovery manager force writes any log records of a transaction remaining in
memory.

Database Backup
A backup is a copy of all or part of a disk. The backup is used when the disk
containing the database or log is damaged. A backup is usually made on a magnetic
tape because it is less expensive and more reliable than disk. Periodically, a backup
should be made for both the database and the log. To save time, most backup
schedules include less frequent massive backups to copy the entire contents of a
disk and more frequent incremental backups to copy only the changed part.

Recovery Processes

Samuel Giftson, Dept of Computing, COE, MU 13

 The recovery process depends on the kind of failure. Recovery from a device
failure is simple but can be time consuming, as listed below:
The database is restored from the most recent backup.
Then, the recovery manager applies the redo operator to all committed transactions after
the backup. Because the backup may be several hours to days old, the log must be
consulted to restore transactions committed after the backup.
The recovery process finishes by restarting incomplete transactions.
For local failures and system failures, the recovery process depends on when database
changes are recorded on disk. Database changes can be recorded before the commit
(immediate update) or after the commit (deferred update). The amount of work and
the use of log operations (undo and redo) depend on the timing of database updates.
The remainder of this section describes recovery processes for local and system
failures under each scenario.

Immediate Update
In the immediate update approach, database updates are written to the disk when
they occur. Database writes occur at checkpoint time and when buffers are full. However,
it is essential that database writes occur after writes of the corresponding log records.
This usage of the log is known as the write ahead log protocol. If log records were
written after corresponding database records, recovery would not be possible if a failure
occurred between the time of writing the database records and the log records.
Recovery from a local failure is easy because only a single transaction is affected.
All log records of the transaction are found. The undo operation is then applied to each
log record of the transaction. If a failure occurs during the recovery process, the undo
operation is applied again. The effect of applying the undo operator multiple times is the
same as applying undo one time. After completing the undo operations, the recovery
manager may offer the user the chance to restart the aborted transaction.
Recovery from a system failure is more difficult because all active users are
affected. To help you understand recovery from a system failure, the figure shows the
progress of a number of transactions with respect to the end of a transaction, most recent
checkpoint, and the failure.

Checkpoint Failure

Time

T1

T2

T3

T4

T5

Samuel Giftson, Dept of Computing, COE, MU 14

Figure: Transaction Time line
Each transaction represents a class of transactions. For example, transaction class T1
represents transactions started and finished before the checkpoint (and the failure).
There are no other kinds of transactions possible.
The immediate update approach may involve both undo and redo operations, as
summarized in the following table.

Class Description Restart Work

T1 Finished before CP None
T2 Started before CP; finished before failure
Redo forward from checkpoint
T3 Started after CP; finished before failure
Redo forward from checkpoint
T4 Started before CP; not yet finished Undo backwards from most recent
log record
T5 Started after CP, not yet finished Undo backwards from most recent
log record
Table: Summary of restart work for the immediate update approach

To understand the amount of work necessary, remember that log records are stable at
checkpoint time and end of transaction and database changes are stable at
checkpoint time. Although other database writes occur when a buffer fills, the
timing of other writes is unpredictable. T1 transactions require no work because
both log and database changes are stable before the failure. T2 transactions must be
redone from the checkpoint because only database changes prior to the checkpoint
are stable. T3 transactions must be redone entirely because database changes are
not guaranteed to be stable even though some changes may be recorded on disk. T4
and T5 transactions must be undo entirely because some database changes after the
checkpoint may be recorded on disk.
After a system failure, the checkpoint table and the log are used to restore
transactions to a consistent state. Using the most recent checkpoint record, the
recovery manager locates the log record written at the time of the checkpoint.
Active transactions are classified, as specified in the above table. The recovery
manager applies the undo operator to all T4 and T5 transactions and the redo
operator to all T2 and T3 transactions. Finally, all T4 and T5 transactions are
restarted.

Deferred Update
In the deferred update approach, database updates are written to disk only after a
transaction commits. No database writes occur at checkpoint time except for already
committed transactions. The advantage of the deferred update approach is that undo
operations are not necessary. However, it may be necessary to perform more redo
operations than in the immediate update approach.

Samuel Giftson, Dept of Computing, COE, MU 15

 Local failures are handled without any restart work in the deferred update
approach. Because no database changes occur until after a transaction commits, the
transaction is aborted without any undo work. The recovery manager may still
provide the user with the option of restarting the transaction.
System failures can be handled without undo operations as depicted in the
following table.

Class Description Restart Work

T1 Finished before CP None
T2 Started before CP; finished before failure Redo forward from first log record
T3 Started after CP; finished before failure Redo forward from first log record
T4 Started before CP; not yet finished None
T5 Started after CP, not yet finished None
Table: Summary of restart work for the deferred update approach

T4 and T5 transactions (not yet committed) do not require undo operations because no
database changes are written to disk until after a transaction commits. T2 and T3
transactions (committed after the checkpoint) require redo operations because it is
not known whether all database changes are stable. T2 transactions (started before
the checkpoint) must be redone from their first log record rather than just from the
checkpoint as in the immediate approach. Thus, the deferred approach requires
more restart work for T2 transactions than does the immediate update approach.
However, the deferred update approach requires no restart work for T4 and T5
transactions, while the immediate update approach must undo T4 and T5
transactions.

TP Monitor
Short for Transaction Processing monitor, a program that monitors a transaction
as it passes from one stage in a process to another. The TP monitor's purpose is to ensure
that the transaction processes completely or, if an error occurs, to take appropriate
actions. TP monitors are especially important in three-tier architectures that employ load
balancing because a transaction may be forwarded to any of several servers. In fact, many
TP monitors handle the entire load balancing operations, forwarding transactions to
different servers based on their availability.

Purpose and Origin

Transaction processing (TP) monitor technology provides the distributed
client/server environment the capacity to efficiently and reliably develop, run, and
manage transaction applications.

TP monitor technology controls transaction applications and performs business

logic/rules computations and database updates. TP monitor technology emerged 25 years
ago when Atlantic Power and Light created an online support environment to share
concurrently applications services and information resources with the batch and time-

Samuel Giftson, Dept of Computing, COE, MU 16

sharing operating systems environment. TP monitor technology is used in data
management, network access, security systems, delivery order processing, airline
reservations, and customer service. Use of TP monitor technology is a cost-effective
alternative to upgrading database management systems or platform resources to provide
this same functionality. TP monitor technology is software that is also referred to as
Middleware. It can provide application services to thousands of clients in a distributed
client/server environment. TP monitor technology does this by multiplexing client
transaction requests (by type) onto a controlled number of processing routines that
support particular services. These events are depicted in Figure.

Figure: Transaction Processing Monitor Technology

Clients are bound, serviced, and released using stateless servers that minimize overhead.
The database sees only the controlled set of processing routines as clients. TP monitor
technology maps numerous client requests through application services routines to
improve system performance. The TP monitor technology (located as a server) can also
take the application transitions logic from the client. This reduces the number of upgrades
required by these client platforms. In addition, TP monitor technology includes numerous
management features, such as restarting failed processes, dynamic load balancing, and
enforcing consistency of distributed data. It is easily scalable by adding more servers to
meet growing numbers of users.

It is independent of the database architecture. It supports flexible and robust

business modeling and encourages modular, reusable procedures. TP monitor designs
allow Application Programming Interfaces (APIs) to support components such as
heterogeneous client libraries, databases and resource managers, and peer-level
application systems. It supports architecture flexibility because each component in a
distributed system is comprised of products that are designed to meet specific
functionality, such as graphical user interface builders and database engines.

Samuel Giftson, Dept of Computing, COE, MU 17

Usage Considerations
Within distributed client/server systems, each client that is supported adds
overhead to system resources (such as memory). Responsiveness is improved and system
resource overhead is reduced by using this technology to multiplex many clients onto a
much smaller set of application service routines. This technology provides a highly active
system that includes services for delivery order processing, terminal and forms
management, data management, network access, authorization, and security. TP monitor
technology supports a number of program-to-program communication models, such as
store-and-forward, asynchronous, Remote Procedure Call (RPC), and conversational.
This improves interactions among application components. It provides the ability to
construct complex business applications from modular, well-defined functional
components. Because this technology is well known and well defined it should reduce
program risk and associated costs. A limitation to TP technology is that the
implementation code is usually written in a lower-level language (such as COBOL), and
is not yet widely available in the popular visual tool sets.
A variation of TP monitor technology is session-based technology. In the TP
monitor technology, transactions from the client are treated as messages. In the session
based technology, a single server provides both database and transaction services. In
session based technology, the server must be aware of clients in advance to maintain each
client's processing thread. The session server must constantly send messages to the client
(even when work is not being done in the client) to ensure that the client is still alive.
Session based architectures are not as scalable because of the adverse effect on network
performance as the number of clients grow.

Another alternative to TP monitor technology is remote data access (RDA). The

RDA centers the application in a client computer, communicating with back-end database
servers. Clients can be network-intensive, but scalability is limited.

A third alternative to TP monitor technology is the database server approach,

which provides functions (usually specific to the database) and is architecturally locked
to the specific database system.

Samuel Giftson, Dept of Computing, COE, MU 18