ADVANCED DATABASE MANAGEMENT

SYSTEMS
ICT3273

Transaction Processing Concepts I

Nuwan Laksiri
Department of ICT
Faculty of Technology
University of Ruhuna Lecture 08
 WHAT WE DISCUSS TODAY ……..
• INTRODUCTION TO TRANSACTION PROCESSING
• NEED FOR CONCURRENCY CONTROL
• THE LOST UPDATE PROBLEM
• THE TEMPORARY UPDATE (OR DIRTY PROBLEM
• THE INCORRECT SUMMARY PROBLEM
• THE UNREPEATABLE READ
• TRANSACTION AND SYSTEM CONCEPTS
• DESIRABLE PROPERTIES OF TRANSACTIONS
• ACID

NEXT WEEK
• TRANSACTION MANAGEMENT II
• CHARACTERIZING SCHEDULES BASED ON RECOVERABILITY
• CHARACTERIZING SCHEDULES BASED ON SERIALIZABILITY
• TRANSACTION RECOVERY
 RECAP
• INTRODUCTION TO QUERY OPTIMIZATION
• TRANSFORMATION OF RELATIONAL EXPRESSIONS
• EQUIVALENT RULES
• COST BASED OPTIMIZATION
• HEURISTIC OPTIMIZATION
 Single User Versus Multiuser Systems
Single-User System
• A DBMS is single user if at most one user at a time can use the
system
Multi-user System
• A DBMS is multiuser if many users can use the system and hence
access the database concurrently

Multiprogramming
• Multiple users can access databases and use computer systems
simultaneously because of the concept of multiprogramming
• Allows the computer to execute multiple programs or processes
at the same time
Multiprogramming Operating Systems
• If only a single central processing unit (CPU) exists…
• Execute at most one program at a time
• Execute some commands from one program
• Then suspend that program and execute some
commands from the next program
Multiprogramming Operating Systems
• Concurrent execution of programs is actually
interleaved
• If the computer system has multiple CPUs parallel
processing is possible
 Transaction
• An executing program that forms a logical unit of
database processing is called a Transaction
• It May include
• Insertion, deletion, modification, or retrieval operations
• Transaction boundaries
• Begin transaction and end transaction
• All database access operations between these two
are form a single transaction
• One application may include several transactions
 Simple Model of a Database
(for the purposes of discussing transactions):
• A database is a collection of named data items
• Granularity of data - a field, a record , or a whole disk
block (Concepts are independent of granularity)
• Basic operations are read and write
• read_item(X):
• Reads a database item named X into a program variable.
• To simplify our notation, we assume that the program
variable is also named X.
• write_item(X):
• Writes the value of program variable X into the database
item named X.
 Read and Write Operations
• read_item(X) command includes the following steps:
• Find the address of the disk block that contains item X.
• Copy that disk block into a buffer in main memory (if that disk
block is not already in some main memory buffer).
• Copy item X from the buffer to the program variable named X.
• write_item(X) command includes the following steps:
• Find the address of the disk block that contains item X.
• Copy that disk block into a buffer in main memory (if that disk block is
not already in some main memory buffer).
• Copy item X from the program variable named X into its correct
location in the buffer.
• Store the updated block from the buffer back to disk (either
immediately or at some later point in time).
 Two Sample Transactions
• Two sample transactions:
• (a) Transaction T1
• (b) Transaction T2
 Need For Concurrency Control
Problems occur when transactions are executed
concurrently
• The Lost Update Problem
• The Temporary Update (or Dirty Problem
• The Incorrect Summary Problem
• The Unrepeatable read
 The Lost Update Problem
• This occurs when two transactions that access the same
database items have their operations interleaved in a way that
makes the value of some database item incorrect.
 The Temporary Update/Dirty Read
Problem
• This occurs when one transaction updates a database item and then the
transaction fails for some reason
• The updated item is accessed by another transaction before it is changed
back to its original value.
 The Incorrect Summary Problem
• If one transaction is calculating an aggregate summary function on
several records while other transactions are updating some of
these records, the aggregate function may calculate some values
before they are updated and others after they are updated.
 The Unrepeatable Read Problem
• A transaction T reads an item twice and the item is
changed by another transaction T' between the two
reads
• Hence, T receives different values for its two reads of
the same item.

• Example ???
 Need for recovery
(What causes a Transaction to fail)

1. A computer failure (system crash):

• A hardware or software error occurs in the computer
system during transaction execution. If the hardware
crashes, the contents of the computer’s internal memory
may be lost.
2. A transaction or system error:
• Some operation in the transaction may cause it to fail,
such as integer overflow or division by zero.
Transaction failure may also occur because of
erroneous parameter values or because of a logical
programming error. In addition, the user may interrupt
the transaction during its execution.
 Need for recovery
(What causes a Transaction to fail)

3. Local errors or exception conditions detected by the

transaction:
• Certain conditions necessitate cancellation of the
transaction.
• For example, data for the transaction may not be found.
• A condition, such as insufficient account balance in a banking
database, may cause a transaction, such as a fund
withdrawal from that account, to be canceled.
• A programmed abort in the transaction causes it to fail.
4. Concurrency control enforcement:
• The concurrency control method may decide to abort the
transaction, to be restarted later, because it violates
serializability or because several transactions are in a state
of deadlock
 Need for recovery
(What causes a Transaction to fail)

5. Disk failure:
• Some disk blocks may lose their data because of a
read or write malfunction or because of a disk
read/write head crash. This may happen during a
read or a write operation of the transaction.
6. Physical problems and catastrophes:
• This refers to an endless list of problems that includes
power or air-conditioning failure, fire, theft, sabotage,
overwriting disks or tapes by mistake, and mounting of
a wrong tape by the operator.
 Transaction and System Concepts
• A transaction is an atomic unit of work that is either
completed in its entirety or not done at all.
• For recovery purposes, the system needs to keep track of
when the transaction starts, terminates, and commits or
aborts.
• Transaction states:
• Active state
• Partially committed state
• Committed state
• Failed state
• Terminated State
 Transaction Recovery
Recovery manager keeps track of the following operations:
• begin_transaction:
• This marks the beginning of transaction execution.
• read or write:
• These specify read or write operations on the database items
that are executed as part of a transaction.
• end_transaction:
• This specifies that read and write transaction operations have
ended and marks the end limit of transaction execution.
• At this point it may be necessary to check whether the changes
introduced by the transaction can be permanently applied to the
database or whether the transaction must be aborted because it
violates concurrency control or for some other reason.
 Transaction Recovery
Recovery manager keeps track of the following operations
(cont):
• commit_transaction:
• This signals a successful end of the transaction so that any
changes (updates) executed by the transaction can be
safely committed to the database and will not be undone.
• rollback (or abort):
• This signals that the transaction has ended unsuccessfully, so
that any changes or effects that the transaction may have
applied to the database must be undone.
 Transaction Recovery
Recovery techniques use the following operators:
• undo:
• Like rollback except that it applies to a single
operation rather than to a whole transaction.
• redo:
• This specifies that certain transaction operations must
be redone to ensure that all the operations of a
committed transaction have been applied successfully
to the database.
State Transition Diagram Illustrating
the States for Transaction Execution
 The System Log
• Log or Journal:
The log keeps track of all transaction operations that
affect the values of database items.
• This information may be needed to permit recovery
from transaction failures.
• The log is kept on disk, so it is not affected by any type
of failure except for disk or catastrophic failure.
• In addition, the log is periodically backed up to
archival storage (tape) to guard against such
catastrophic failures.
 The System Log
• T in the following discussion refers to a unique transaction-id that is
generated automatically by the system and is used to identify each
transaction:
• Types of log record:
• [start_transaction,T]: Records that transaction T has started
execution.
• [write_item,T,X,old_value,new_value]: Records that transaction T
has changed the value of database item X from old_value to
new_value.
• [read_item,T,X]: Records that transaction T has read the value of
database item X.
• [commit,T]: Records that transaction T has completed successfully
and affirms that its effect can be committed (recorded
permanently) to the database.
• [abort,T]: Records that transaction T has been aborted.
 The System Log
• Protocols for recovery that avoid cascading rollbacks
do not require that read operations be written to the
system log, whereas other protocols require these
entries for recovery.
• Strict protocols require simpler write entries that do
not include new_value
 Recovery Using Log Records
• If the system crashes, we can recover to a consistent
database state by examining the log
• Because the log contains a record of every write operation
that changes the value of some database item, it is possible
to undo the effect of these write operations of a
transaction T by tracing backward through the log and
resetting all items changed by a write operation of T to
their old_values.
• We can also redo the effect of the write operations of a
transaction T by tracing forward through the log and setting
all items changed by a write operation of T (that did not
get done permanently) to their new_values.
 Commit Point of a Transaction
• Definition of a Commit Point:
• A transaction T reaches its commit point when all its
operations that access the database have been executed
successfully and the effect of all the transaction operations
on the database has been recorded in the log.
• Beyond the commit point, the transaction is said to be
committed, and its effect is assumed to be permanently
recorded in the database.
• The transaction then writes an entry [commit,T] into the log.
• Roll Back of transactions:
• Needed for transactions that have a [start_transaction,T]
entry into the log but no commit entry [commit,T] into the
log.
 Commit Point of a Transaction
• Redoing transactions:
• Transactions that have written their commit entry in the log must
also have recorded all their write operations in the log;
otherwise, they would not be committed, so their effect on the
database can be redone from the log entries. (Notice that the
log file must be kept on disk.
• At the time of a system crash, only the log entries that have been
written back to disk are considered in the recovery process
because the contents of main memory may be lost.)
• Force writing a log:
• Before a transaction reaches its commit point, any portion of the
log that has not been written to the disk yet must now be written
to the disk.
• This process is called force-writing the log file before committing
a transaction.
 Desirable Properties of Transactions
• ACID properties:
• Atomicity: A transaction is an atomic unit of processing; it is
either performed in its entirety or not performed at all.
• Consistency preservation: A correct execution of the
transaction must take the database from one consistent state to
another.
• Isolation: A transaction should not make its updates visible to
other transactions until it is committed; this property, when
enforced strictly, solves the temporary update problem and
makes cascading rollbacks of transactions unnecessary
• Durability or permanency: Once a transaction changes the
database and the changes are committed, these changes must
never be lost because of subsequent failure.
 Atomicity
• The transaction is atomic
• fully completed, or
• is not begun at all
• If for any reason an error occurs
• Then the system is returned to the state it was in before the
transaction was started
Example:
An account transfer transaction
• The money is removed from account A then placed into
account B. If the system fails after removing the money from
account A, then the transaction processing system will put
the money back into account A, thus returning the system to
its original state Rollback
 Consistency
• At the end of any transaction
• The system should be in a valid state
• If it is completely executed from beginning to end without
interference from other transactions
• it should take the database from one consistent state to another
Example:
Account transfer system
• The system is consistent if the total of all accounts is constant .
If an error occurs and the money is removed from account A
and not added to account B, then the total in all accounts
would have changed . The system would no longer be
consistent . By rolling back the removal from account A, the
total will again be what it should be
 Isolation
• The execution of a transaction should not be interfered
by any other transactions executing concurrently
• It appears to be the only action that the system is
carrying out at one time
• If not, it could access data from the system that may
not be consistent
 Durability
• Once a transaction has been successfully completed,
all of the changes it made to the system are
permanent
• There are safeguards that will prevent the loss of
information, even in the case of system failure
• Eg: system logs
 HOMEWORK
Find about following concepts related to the lesson
• Schedules
• Recoverability
• Serializability
• Reliable and Reliability
• Failure, Error and Fault
• Do, Undo, Redo
 SUMMARY
• INTRODUCTION TO TRANSACTION PROCESSING
• TRANSACTION AND SYSTEM CONCEPTS
• DESIRABLE PROPERTIES OF TRANSACTIONS
• ACID
 REFERENCES
• Fundamentals of database systems
(6th edition) by remez elmasri & shamkant B. Navathe )

• Database Management Systems

(3rd edition) - by Raghu Ramakrishnan and Johannes Gehrke, McGraw Hill,
2003.

• Advanced Database Management Systems

by Rini Chakrabarti, Shibhadra Dasgupta
THANK YOU