Transactions

Transaction

A transaction is an action, or a series of actions,

carried out by a single user or an application
program, which reads or updates (writes) the
contents of a database.
 Any action that reads from and/or writes to a database may consist of
 Simple SELECT statement to generate a list of table contents
 A series of related UPDATE statements to change the values of attributes in various
tables
 A series of INSERT statements to add rows to one or more tables
 A combination of SELECT, UPDATE, and INSERT statements
Let T1 transfers $50 from A to B, and T2 transfers
$100 from B to C.
Transaction

 A logical unit of work that must be either entirely completed or aborted

 Successful transaction changes the database from one consistent state to another
 One in which all data integrity constraints are satisfied
 Most real-world database transactions are formed by two or more database requests
 The equivalent of a single SQL statement in an application program or transaction

 Some examples of transactions are

 Money transactions
 Ticket booking
 Online admission
 Remote gaming
Transaction Concept
 A transaction is a unit of program execution that accesses and possibly
updates various data items.
 E.g. 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)
 Two main issues to deal with:
 Failures of various kinds, such as hardware failures and system crashes
 Concurrent execution of multiple transactions
Example of multiple Transactions
 Let T1 transfers $50 from A to B, and T2 transfers 10% of the balance from A to B.
 Here T1 and T2 are two transactions and T1 is followed by T2.
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 Management with SQL
 ANSI has defined standards that govern SQL database transactions
 Transaction support is provided by two SQL statements: COMMIT and
ROLLBACK
 ANSI standards require that, when a transaction sequence is initiated
by a user or an application program, it must continue through all
succeeding SQL statements until one of four events occurs

1. A COMMIT statement is reached- all changes are permanently

recorded within the database
2. A ROLLBACK is reached – all changes are aborted and the
database is restored to a previous consistent state
3. The end of the program is successfully reached – equivalent to
a COMMIT
4. The program abnormally terminates and a rollback occurs
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.
Transaction State (Cont.)
Example of Fund Transfer
 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)
 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
 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.
Example of Fund Transfer (Cont.)
 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)
 Consistency requirement in above example:
 the sum of A and B is unchanged by the execution of the transaction
 In general, consistency requirements include
 Explicitly specified integrity constraints such as primary keys and foreign keys
 Implicit integrity constraints
 e.g. sum of balances of all accounts, minus sum of loan amounts must equal
value of cash-in-hand
 A transaction must see a consistent database.
 During transaction execution the database may be temporarily inconsistent.
 When the transaction completes successfully the database must be consistent
 Example of Fund Transfer (Cont.)

 Isolation requirement — if between steps 3 and 6, 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.
 However, executing multiple transactions concurrently has significant benefits, like
it will reduce time, increase modularity, give the advantage of remote access…
The Transaction Log

 Keeps track of all transactions that update the database. It

contains:
 A record for the beginning of transaction
 For each transaction component (SQL statement)
 Type of operation being performed (update, delete, insert)
 Names of objects affected by the transaction (the name of the table)
 “Before” and “after” values for updated fields
 Pointers to previous and next transaction log entries for the same
transaction
 The ending (COMMIT) of the transaction
 Increases processing overhead but the ability to restore a corrupted
database is worth the price
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 schemes – mechanisms to achieve isolation
 that is, to control the interaction among the concurrent transactions in order
to prevent them from destroying the consistency of the database
Transactions
Schedules
 Schedule – a sequences of instructions that specify the chronological
order in which instructions of concurrent transactions are executed
 a schedule for a set of transactions must consist of all instructions of those
transactions
 must preserve the order in which the instructions appear in each individual
transaction.
 A transaction that successfully completes its execution will have a commit
instructions as the last statement
 by default transaction assumed to execute commit instruction as its last step
 A transaction that fails to successfully complete its execution will have an
abort instruction as the last statement
 Schedule 1
 Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from A to B.
 A serial schedule in which T1 is followed by T2 :
Before transaction: A=500
B=600 Total=1100
A=500 After Transaction : A=405
A=450 B=695 Total=1100

B=600
B=650

A=450
temp=45
A=405

B=650
B=695
 Before transaction: A=500

Schedule 2 B=600 Total=1100

• A serial schedule where T2 is followed by T1

Schedule 3

 Let T1 and T2 be the transactions defined previously. The following schedule is not a
serial schedule, but it is equivalent to Schedule 1.
Before transaction: A=500
B=600

After Transaction : A=405

B=695

In Schedules 1, 2 and 3, the sum A + B is preserved.

 Before transaction:

Schedule 4 A=500

B=600 Total=1100
 The following concurrent schedule does not preserve the value of (A + B ).

A(D)=600, B(D)=500 A(D)=600, B(D)=500

A(M)=600
A(M)=550
A(D)=540
B(M)=500

A(D)=550

B(D)=550
B(M)=56
0
B(D)=560