TRANSACTION

Def. Logical unit of work that must be entirely completed or aborted

Def. A transaction is a program including a collection of database operations, executed as a logical unit
of data processing.
 Transactions can be either single user processing/ multi user processing.
 The operations performed in a transaction include one or more of database operations like insert,
delete, update or retrieve data.
 It is an atomic process that is either performed into completion entirely or is not performed at all.
 A transaction involving only data retrieval without any data update is called read-only transaction.
 Each high level operation can be divided into a number of low level tasks or operations. For
example, a data update operation can be divided into three tasks:
 ..continuation

i. read_item() − reads data item from storage to main memory/(database retrieval, such as SQL
SELECT).
ii. modify_item() − change value of item in the main memory.
iii. write_item() − write the modified value from main memory to storage/(modify database, such as
SQL INSERT, UPDATE, DELETE).
 Database access is restricted to read_item() and write_item() operations. Likewise, for all
transactions, read and write forms the basic database operations and also a combination of
SELECT, UPDATE, and INSERT statements
 Example from banking database: Transfer of $100 dollars from a checking account to a savings
account.
 Note: Each execution of a program is a distinct transaction with different parameters.
Bank transfer program parameters: savings account number, checking account number, transfer
amount.
 Basic operations (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.
 read_item(X) command includes the following steps:
i. Find the address of the disk block that contains item X.
ii. Copy that disk block into a buffer in main memory (if that disk
iii. block is not already in some main memory buffer).
iv. Copy item X from the buffer to the program variable named X.
 Basic operations (read and write)
 write_item(X): Writes the value of program variable X into the database item named X.
 write_item(X) command includes the following steps:
i. Find the address of the disk block that contains item X.
ii. Copy that disk block into a buffer in main memory (if that disk block is not already in some
main memory buffer).
iii. Copy item X from the program variable named X into its correct location in the buffer.
iv. Store the updated block from the buffer back to disk (either immediately or at some later
point in time).
 Transactions boundaries
 Transaction boundaries: Begin transaction and End transaction
 Application program may include specification of several transactions separated by Begin and End
transaction boundaries.
 Transaction code can be executed several times (in a loop), spawning multiple transactions.
 Transactions can end in two states:
i. Commit: transaction successfully completes and its results are committed (made permanent)
ii. Abort: transaction does not complete and none of its actions are reflected in the database
..continuation
 Transaction operations

i. begin transaction − A marker that specifies start of transaction execution.

ii. read item or write item − Database operations that may be interleaved with main memory
operations as a part of transaction.
iii. end transaction − A marker that specifies end of transaction.
iv. commit − A signal to specify that the transaction has been successfully completed in its entirety
and will not be undone.
v. rollback − A signal to specify that the transaction has been unsuccessful and so all temporary
changes in the database are undone. A committed transaction cannot be rolled back.
 Transaction states
 A transaction may go through a subset of 5:
i. Active − The initial state where the transaction enters is the active state. The transaction
remains in this state while it is executing read, write or other operations.
ii. Partially Committed − The transaction enters this state after the last statement of the
transaction has been executed.
iii. Committed − The transaction enters this state after successful completion of the transaction
and system checks have issued commit signal.
iv. Failed − The transaction goes from partially committed state or active state to failed state
when it is discovered that normal execution can no longer proceed or system checks fail.
v. Aborted − This is the state after the transaction has been rolled back after failure and the
database has been restored to its state that was before the transaction began.
State transition-Transaction operations diagram
 Desirable Properties of Transactions
(ACID)

i. Atomicity − This property states that a transaction is an atomic unit of processing, that is, either it is
completed or not performed at all. No partial update should exist.
ii. Consistency − A transaction should take the database from one consistent state to another consistent
state. It should not adversely affect any data item in the database.
iii. Isolation − A transaction should be executed as if it is the only one in the system. There should not be
any interference from the other concurrent transactions that are simultaneously running.
iv. Durability − If a committed transaction brings about a change, that change should be durable in the
database and not lost in case of any failure.
 Enforcement of ACID properties:
i. Database constraint system (and application program correctness) responsible for C (introduced in
previous classes)
ii. Concurrency control responsible for I (more in next class)
iii. Recovery system responsible for A and D (more in next class)
 Transaction Support In SQL
 A single SQL statement is always considered to be atomic:
Either the statement completes execution without error or it fails and leaves the database
unchanged.
 No explicit Begin Transaction statement:
Transaction initiation implicit at first SQL statement and at next SQL statement after previous
transaction terminates
 Every transaction must have an explicit end statement
COMMIT: the DB must assure that the effects are permanent
ROLLBACK: the DB must assure that the effects are as if the transaction had not yet begun
 example
update_proc() {
EXEC SQLWHENEVER SQLERROR GO TO error;
EXEC SQL INSERT
INTO EMPLOYEE
VALUES ('Robert','Smith','991004321',2,35000);
EXEC SQLUPDATE EMPLOYEE
SET SALARY = SALARY * 1.1
WHERE DNO = 2;
EXEC SQLCOMMIT;
return(0);
error: /* continue if error on rollback */
EXEC SQLWHENEVER SQLERROR CONTINUE;
EXEC SQLROLLBACK;
return(1);
}