What is a Transaction?

04. Transaction Processing

Any action that reads from and/or writes to a database. It may consist of:
Simple SELECT statement to generate list of table contents Series of related UPDATE statements to change values of attributes in various tables Series of INSERT statements to add rows to one or more tables Combination of SELECT, UPDATE, and INSERT statements
1 A Karwega 2

What is a Transaction?
Transaction is logical unit of work that must be either entirely completed or aborted Successful transaction changes database from one consistent state to another
Consistent State: One in which all data integrity constraints are satisfied

Single User vs. Multi-User Systems Single-User System: At most one user at a time
can use the system e.g. Personal Computer Systems

Multiuser System: Many users can access the

system concurrently e.g.
Airline Reservations System with hundreds of travel agents and reservations clerks Banks Insurance Agencies Stock Exchanges Supermarkets etc.

Most real-world database transactions are formed by two or more database requests
Equivalent of a single SQL statement in an application program or transaction
A Karwega 3

A Karwega

Concurrency
Computers may execute multiple programs/processes at the same time => Multiprogramming If only one CPU exists the OS ensures that some commands are executed from one program and then this program is suspended to allow commands from another program to be executed Interleaved processing: concurrent execution of processes is interleaved in a single CPU If multiple CPUs exist then parallel processing may happen i.e. processes are concurrently executed in the multiple CPUs.
A Karwega 5

Interleaved Processing vs Parallel Processing

A B

A B

C D

CPU1 CPU2

t1

t2

t3

t4

time

A Karwega

Introduction to Transaction Processing A transaction (set of operations) may be standalone specified in a high level language like SQL submitted interactively, or may be embedded within a program.

Introduction to Transaction Processing

SIMPLE MODEL OF A DATABASE: A database - collection of named data items Granularity of data - a field, a record , or a whole
disk block

Transaction boundaries: Begin and End

transaction.

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.
A Karwega 8

An application program may contain several transactions separated by the transaction boundaries Begin Transaction and End Transaction.
A Karwega 7

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:
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 buffer to the program variable named X.
A Karwega 9

WRITE OPERATION
1. 2. 3. 4. 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).
A Karwega 10

Sample Transactions

Sample Transaction
Assume:
T1 and T2 are transactions in a much simplified airline reservation database system T1 transfers N reservations from one flight whose number of reserved seats is stored in a database item X to another flight whose number of reserved seats is stored in database item Y T2 reserves M seats on the first flight X

The two are transactions run concurrently

A Karwega 11 A Karwega 12

Necessity for Concurrency Control:

Lost Update Problem

The Lost Update 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 item incorrect. See fig on next slide the final value of X is incorrect.
13 14

A Karwega

A Karwega

Necessity for Concurrency Control The Temporary Update (or Dirty Read) Problem.
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.
A Karwega 15

Temporary Update Problem

A Karwega

16

Necessity for Concurrency Control

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.
17

Incorrect Summary Problem

A Karwega

A Karwega

18

Necessity for Recovery

The DBMS is responsible for ensuring that either:
All operations in a transaction are completed successfully and their effect permanently recorded in the database, or The transaction has no effect whatsoever on the database or other transactions It must not permit some operations to be applied while others are not ( a challenge that occurs when transactions fail)
A Karwega 19

Why would a transaction fail?

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 computers internal memory may be lost. 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.
A Karwega 20

Why would a transaction fail?

Local errors or exception conditions detected by the transaction:
Certain conditions necessitate cancellation of the transaction. E.g., 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 trans. causes it to fail.

Why Would a Transaction Fail?

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. 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.
A Karwega 22

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.
A Karwega 21

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, commits or aborts.
Transaction states: Active state Partially committed state Committed state Failed state Terminated State

States for transaction execution.

A Karwega

23

A Karwega

24

DBMSs Recovery Manager Monitors:

begin_transaction:
Marks the beginning of transaction execution.

DBMSs Recovery Manager Monitors: commit_transaction:

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.

read or write:
Specify read or write operations on the database items that are executed as part of a transaction.

end_transaction:
Specifies that read and write transaction operations have ended 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 has to be aborted for any reason.
A Karwega 25

rollback (or abort):

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.
A Karwega 26

Recovery Techniques undo: Similar to 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.
A Karwega 27

The System Log/Journal:

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, and should be periodically backed up to archival storage (tape) to guard against such catastrophic failures.
A Karwega 28

A Transaction Log

Transaction & System Concepts

If the system crashes, we can recover to a consistent database state by examining the log By tracing backwards through records in the log, it is possible to undo the effect of write operations of a transaction T then use 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 to their new_values.

A Karwega

29

A Karwega

30

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.
A Karwega 31

Commit Point: 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.

A Karwega

32

Desirable Properties of Transactions Atomicity, Consistency Preservation, Isolation, Durability/Permanency (ACID)

Atomicity:
A transaction is an atomic unit of processing; it is either performed in its entirety or not performed at all.

Desirable Properties of Transactions

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: Consistency preservation:

A correct execution of the transaction must take the database from one consistent state to another.
A Karwega 33

Once a transaction changes the database and the changes are committed, these changes must never be lost because of subsequent failure.
A Karwega 34

Purpose of Concurrency Control

To enforce Isolation (through mutual exclusion) among conflicting transactions. To preserve database consistency through execution of consistency preserving transactions. To resolve read-write and write-write conflicts.
Example:
In concurrent execution environment if T1 conflicts with T2 over a data item A, then the existing concurrency control decides if T1 or T2 should get the A and if the other transaction is rolled-back or waits.
35 A Karwega 36

Concurrency Control

Two-Phase Locking Techniques

Locking is an operation which secures
a) permission to Read or b) permission to Write a data item for a transaction. Example: Lock (X). Data item X is locked on behalf of the requesting transaction.

Locking Techniques: Essential Components

Unlocking is an operation which removes these permissions from the data item. Example:
Unlock (X). Data item X is made available to all other transactions.

Lock Manager: Managing locks on data items. A mechanism to enforce data locks Lock table: Lock manager uses it to store the identify of transaction locking a data item, the data item, lock mode and pointer to the next data item locked.
A dynamic record of transaction locking data
Transaction ID Data item id lock mode Ptr to next data item T1 X1 Read Next

Lock and Unlock are Atomic operations.

A Karwega 37

A Karwega

38

Granularity of data items

Granularity = A lockable unit of data Data item granularity significantly affects concurrency control performance. Example of data item granularity:
A field of a database record (an attribute of a tuple). A database record (a tuple or a relation). A disk block. An entire Table. The entire database 39

Lock Granularity (continued)

Row-level lock
Allows concurrent transactions to access different rows of same table, even if rows are located on same page

Field-level lock
Allows concurrent transactions to access same row, as long as they require use of different fields (attributes) within that row

A Karwega

A Karwega

40

Purpose of Database Recovery

To bring the database into the last consistent state, which existed prior to the failure.

Database Recovery

To preserve transaction properties (Atomicity, Consistency, Isolation and Durability). Example:

If the system crashes before a fund transfer transaction completes its execution, then either one or both accounts may have incorrect value. Thus, the database must be restored to the state before the transaction modified any of the accounts.
41 A Karwega 42

Types of Failure (discussed before)

System Failure: addressing error, application error, operating system fault, RAM failure Transaction Failure: due to incorrect input, deadlock, incorrect synchronization Media Failure: Disk head crash, power disruption
For recovery from any type of failure data values prior to modification (Before Image, BFIM)and the new value after modification (After Image, AFIM) are stored in the Transaction log.
A Karwega 43

Data Update: Alternative Schemes Immediate Update: As soon as a data item is modified in cache, the disk copy is updated. Deferred Update: All modified data items in the cache is written either after a transaction ends its execution or after a fixed number of transactions have completed their execution. Shadow update: The modified version of a data item does not overwrite its disk copy but is written at a separate disk location. In-place update: The disk version of the data item is overwritten by the cache version.
A Karwega 44

Transaction Roll-back (Undo) and RollForward (Redo)

To maintain atomicity, a transactions operations are redone or undone.
Undo: Restore all BFIMs on to disk (Remove all AFIMs). Redo: Restore all AFIMs on to disk.

Checkpointing Time to time (randomly or under some criteria) the database flushes its buffer to database disk to minimize the task of recovery. The following steps defines a checkpoint operation:
1. 2. 3. 4. Suspend execution of transactions temporarily. Force write modified buffer data to disk. Write a [checkpoint] record to the log, save the log to disk. Resume normal transaction execution.

Database recovery is achieved either by performing only Undos or only Redos or by a combination of the two. These operations are recorded in the log as they happen.
A Karwega 45

During recovery redo or undo is required to transactions appearing after [checkpoint] record.

A Karwega

46

Recovery Schemes: Deferred Update (No Undo/Redo) The data update goes as follows:
1. A set of transactions records their updates in the log. 2. At commit point these updates are saved on database disk.
(a)

Database Recovery
Deferred Update in a single-user system
T1 read_item (A) read_item (D) write_item (D) T2 read_item (B) write_item (B) read_item (D) write_item (A)

(b) [start_transaction, T1] [write_item, T1, D, 20] [commit T1] [start_transaction, T1] [write_item, T2, B, 10] [write_item, T2, D, 25] system crash The [write_item, ] operations of T1 are redone. T2 log entries are ignored by the recovery manager.

After reboot from a failure the log is used to redo all the transactions affected by this failure. No undo is required because no AFIM is flushed to the disk before a transaction commits.
A Karwega 47

A Karwega

48

Recovery Schemes: Immediate Update

1. Undo/No-redo Algorithm
In this algorithm AFIMs of a transaction are flushed to the database disk before it commits. The recovery manager undoes all transactions during recovery. No transaction is redone. It is possible that a transaction might have completed execution and ready to commit but this transaction is also undone.

Recovery Schemes: Immediate Update

2. Undo/Redo Algorithm

Recovery schemes of this category apply undo and also redo for recovery. In a single-user environment no concurrency control is required Note that at any time there will be one transaction in the system and it will be either in the commit table or in the active table. The recovery manager performs:
Undo of a transaction if it is in the active table. Redo of a transaction if it is in the commit table.

A Karwega

49

A Karwega

50

Recovery Schemes: Shadow Paging

The AFIM does not overwrite its BFIM but recorded at another place on the disk. Thus, at any time a data item has AFIM and BFIM (Shadow copy of the data item) at two different places on the disk.
X Y X' Database
X and Y: Shadow copies of data items X` and Y`: Current copies of data items
A Karwega 51

Y'