Transaction Processing

Introduction
• A transaction is an executing program that forms a
logical unit of database processing.
• A transaction includes one or more access operations
(read, write, update, or delete).
• Basic operations are read and write
▫ read(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(X): Writes the value of program variable X into
the database item named X.
Executing a read_item(X) command includes the
following steps:
1. Find the address of the disk block that contains item X.
2. Copy that disk block into a buffer in main memory (if
that disk block is not already in some main memory
buffer). The size of the buffer is the same as the disk block
size.
3. Copy item X from the buffer to the program variable
named X.
Executing a write_item(X) command includes the
following steps:
1. Find the address of the disk block that contains item X.
2. Copy that disk block into a buffer in main memory (if
that disk block is not already in some main memory
buffer).
3. Copy item X from the program variable named X into
its correct location in the buffer.
4. Store the updated disk block from the buffer back to
disk (either immediately or at some later point in time).
Example
• 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)
ACID Properties
• 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
ACID Properties
• Consistency requirement
▫ The sum of A and B is unchanged by the execution of the
transaction.
▫ A transaction, when starting to execute, 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
ACID Properties
• Isolation requirement
▫ If between steps 3 and 6 (of the fund transfer transaction) , 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.
ACID Properties
• 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.
 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.
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.
▫ 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.
Transaction State
The System Log
• The log is a sequential, append-only file that is kept on disk, so it is
not affected by any type of failure except for disk or catastrophic
failure.
• To be able to recover from failures that affect transactions, the
system maintains the log to keep track of all transaction operations
that affect the values of database items.
• 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.
• Redo of an operation may also be necessary if a transaction has its
updates recorded in the log but a failure occurs before the system
can be sure that all these new_values have been written to the
Sample log records
1. [start_transaction, T]. Indicates that transaction T has
started execution.
2. [write_item, T, X, old_value, new_value]. Indicates
that transaction T has changed the value of database item
X from old_value to new_value.
3. [read_item, T, X]. Indicates that transaction T has read
the value of database item X.
4. [commit, T]. Indicates that transaction T has completed
successfully, and affirms that its effect can be committed
(recorded permanently) to the database.
5. [abort, T]. Indicates that transaction T has been
aborted.
Recovery using log records
If the system crashes, we can recover to a consistent
database state by examining the log and using one
of the techniques described in Chapter 19.
1. 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.
2. 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)
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 is needed
Several problems can occur when concurrent transactions execute in an
uncontrolled manner such as:
• 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.
• 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. Meanwhile, the updated item is
accessed (read) by another transaction before it is changed back (or
rolled back) to its original value.
• 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.
Concurrency Control is needed
The lost update problem
Concurrency Control is needed
• The temporary update problem
Concurrency Control is needed
• Incorrect summary problem