Chapter 17

Introduction to Transaction
Processing Concepts and Theory

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Chapter Outline
1 Introduction to Transaction Processing
2 Transaction and System Concepts
3 Desirable Properties of Transactions
4 Transaction Control Language (TCL)

Slide 17- 2
1 Introduction to Transaction
Processing (1)
 Single-User System:
 At most one user at a time can use the system.
 Multiuser System:
 Many users can access the system concurrently.
 Concurrency
 Interleaved processing:
 Concurrent execution of processes is interleaved in
a single CPU
 Parallel processing:
 Processes are concurrently executed in multiple
CPUs.

Slide 17- 3
Introduction to Transaction Processing (2)
 A Transaction:
 Logical unit of database processing that includes one or more
access operations (read -retrieval, write - insert or update,
delete).
 A transaction (set of operations) may be stand-alone
specified in a high level language like SQL submitted
interactively, or may be embedded within a program.
 Transaction boundaries:
 Begin and End transaction.
 An application program may contain several
transactions separated by the Begin and End transaction
boundaries.

Slide 17- 4
Introduction to Transaction Processing (3)
SIMPLE MODEL OF A DATABASE (for 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.

Slide 17- 5
Introduction to Transaction Processing (4)
READ AND WRITE OPERATIONS:
 Basic unit of data transfer from the disk to the computer
main memory is one block. In general, a data item (what
is read or written) will be the field of some record in the
database, although it may be a larger unit such as a
record or even a whole block.
 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.

Slide 17- 6
Introduction to Transaction Processing (5)
READ AND WRITE OPERATIONS (contd.):
 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).

Slide 17- 7
Two sample transactions
 FIGURE 17.2 Two sample transactions:
 (a) Transaction T1
 (b) Transaction T2

Slide 17- 8
Introduction to Transaction Processing (6)
Why Concurrency Control is needed:
 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 (or Dirty Read) Problem
 This occurs when one transaction updates a database item and then
the transaction fails for some reason (see Section 17.1.4).
 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 a
number of 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.

Slide 17- 9
Concurrent execution is uncontrolled:
(a) The lost update problem.

Slide 17- 10
Concurrent execution is uncontrolled:
(b) The temporary update problem.

Slide 17- 11
Concurrent execution is uncontrolled:
(c) The incorrect summary problem.

Slide 17- 12
Introduction to Transaction
Processing (12)
Why recovery is needed:
(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.

Slide 17- 13
Introduction to Transaction
Processing (13)
Why recovery is needed (Contd.):
(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 (see Chapter 18).

Slide 17- 14
Introduction to Transaction
Processing (14)
Why recovery is needed (contd.):
(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.

Slide 17- 15
2 Transaction and System Concepts (1)
 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

Slide 17- 16
State transition diagram illustrating
the states for transaction execution

Slide 17- 17
3 Desirable Properties of Transactions (1)
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 (see Chapter 21).
 Durability or permanency: Once a transaction changes the
database and the changes are committed, these changes must never
be lost because of subsequent failure.

Slide 17- 18
Database Transactions
A database transaction consists of one of the following:
 DML statements that constitute one consistent change to
the data
 One DDL statement
 One data control language (DCL) statement
Database Transactions: Start and
End
 Begin when the first DML SQL statement is executed.
 End with one of the following events:
 A COMMIT or ROLLBACK statement is issued.
 A DDL or DCL statement executes (automatic commit).
 The user exits SQL Developer or SQL*Plus.
 The system crashes.
Advantages of COMMIT
and ROLLBACK Statements
With COMMIT and ROLLBACK statements, you can:
 Ensure data consistency
 Preview data changes before making changes permanent
 Group logically related operations
Explicit Transaction Control
Statements
Time
COMMIT
Transaction

DELETE
SAVEPOINT
A
INSERT

UPDATE
SAVEPOINT
B
INSERT ROLLBACK ROLLBACK
ROLLBACK to SAVEPOINT A
to SAVEPOINT B
Rolling Back Changes to a Marker
 Create a marker in the current transaction by using the
SAVEPOINT statement.
 Roll back to that marker by using the ROLLBACK TO
SAVEPOINT statement.

UPDATE...
SAVEPOINT update_done;

INSERT...
ROLLBACK TO update_done;
Implicit Transaction Processing
 An automatic commit occurs in the following
circumstances:
 A DDL statement issued
 A DCL statement issued
 Normal exit from SQL Developer or SQL*Plus, without
explicitly issuing COMMIT or ROLLBACK statements
 An automatic rollback occurs when there is an abnormal
termination of SQL Developer or SQL*Plus or a system
failure.
State of the Data Before COMMIT or
ROLLBACK
 The previous state of the data can be recovered.
 The current user can review the results of the DML
operations by using the SELECT statement.
 Other users cannot view the results of the DML statements
issued by the current user.
 The affected rows are locked; other users cannot change
the data in the affected rows.
State of the Data After COMMIT
 Data changes are saved in the database.
 The previous state of the data is overwritten.
 All users can view the results.
 Locks on the affected rows are released; those rows are
available for other users to manipulate.
 All savepoints are erased.
Committing Data
 Make the changes:

DELETE FROM employees

WHERE employee_id = 99999;

INSERT INTO departments

VALUES (290, 'Corporate Tax', NULL, 1700);
 Commit the changes:

COMMIT;
State of the Data After ROLLBACK
Discard all pending changes by using the ROLLBACK
statement:
 Data changes are undone.
 Previous state of the data is restored.
 Locks on the affected rows are released.

DELETE FROM copy_emp;

ROLLBACK ;
State of the Data After ROLLBACK:
Example
DELETE FROM test;
25,000 rows deleted.
ROLLBACK;
Rollback complete.
DELETE FROM test WHERE id = 100;
1 row deleted.
SELECT * FROM test WHERE id = 100;
No rows selected.

COMMIT;
Commit complete.
Statement-Level Rollback
 If a single DML statement fails during execution, only that
statement is rolled back.
 The Oracle server implements an implicit savepoint.
 All other changes are retained.
 The user should terminate transactions explicitly by
executing a COMMIT or ROLLBACK statement.
Read Consistency
 Read consistency guarantees a consistent view of the data
at all times.
 Changes made by one user do not conflict with the
changes made by another user.
 Read consistency ensures that, on the same data:
 Readers do not wait for writers
 Writers do not wait for readers
 Writers wait for writers
Implementing Read Consistency
User A

UPDATE employees Data

SET salary = 7000 blocks
WHERE last_name = 'Grant';

Undo
segments

Changed
SELECT * and unchanged
FROM userA.employees; Read- data
consistent
image Before
change
User B (“old” data)