Transaction

Transaction definition• Supports daily operations of an organization• Collection of database operations• Reliably and efficiently processed as one unit

of work• No lost data– Interference among multiple users– Failures

Airline Transaction Example• START TRANSACTION• Display greeting• Get reservation preferences from user• SELECT departure and return flight records• If reservation is acceptable then• UPDATE seats remaining of departure flight

record• UPDATE seats remaining of return flight record• INSERT reservation record• Print ticket if requested• End If• On Error: ROLLBACK • COMMIT

ATM transaction example• START TRANSACTION• Display greeting• Get account number, pin, type, and amount• SELECT account number, type, and balance• If balance is sufficient then• UPDATE account by posting debit• INSERT history record• Display message and dispense cash• Print receipt if requested• End If• On Error: ROLLBACK • COMMIT

Transaction Properties• Atomic: all or nothing• Consistent: database must be consistent

before and after a transaction• Isolated: no unwanted interference from

other users• Durable: database changes are permanent

after the transaction completes

Serializable schedule• A serializable schedule is a linear

arrangement of the database calls from several transactions with the property: the final database state obtained by executing the calls in schedule order is the same as that obtained by running the transactions in some unspecified serial order.

Serializability thru lock

• A lock is an access privilege on a database object, which the DBMS grant to a particular transaction

• Exclusive locks prevent any current access. A shared lock lets you read an object, but you need an exclusive lock to update it.

Transaction Management with SQL• Transaction support is provided by two SQL

statements: COMMIT and ROLLBACK.• A COMMIT statement is reached, in which

case all changes are permanently recorded within the database. The COMMIT statement automatically ends the SQL transaction.

• A ROLLBACK statement is reached in which case all changes are aborted and the database is rolled back to its previous consistent state.

Serializability Testing and Precedence Graphs/Dependency Graph

• So we need a simple method to test a schedule S and discover whether it is serializable.

• Simple method involves constructing a directed graph called a Precedence Graph from S

• Construct a precedence graph as follows:– a vertex labelled Ti for every transaction in S– an edge from Ti to Tj if any of these three conditions holds:

• Ti executes write(Q) before Tj executes read(Q)• Ti executes read(Q) before Tj executes write(Q)• Ti executes write(Q) before Tj executes write(Q)

– if the graph has a cycle, S is not serializable

• Compute a precedence graph for schedule B (right)

• three vertices (T1, T2, T3)

• edge from Ti to Tj if– Ti writes Q before Tj reads Q – Ti reads Q before Tj writes Q (T1-T2)– Ti writes Q before Tj writes Q

Examples of Conflicts• A conflict exists when two transactions access the same item, and at least

one of the accesses is a write.• 1. lost update problem

• T: transfer $100 from A to C: R(A) W(A) R(C) W(C)• S: transfer $100 from B to C: R(B) W(B) R(C) W(C)

• 2. inconsistent retrievals problem (dirty reads violate consistency)• T: transfer $100 from A to C: R(A) W(A) R(C) W(C)• S: compute total balance for A and C: R(A) R(C)

• 3. nonrepeatable reads• T: transfer $100 from A to C: R(A) W(A) R(C)

W(C)• S: check balance and withdraw $100 from A: R(A) R(A) W(A)

Serializable schedule• A schedule is a partial ordering of operations for a set of transactions

{T,S,...}, such that:– The operations of each action execute serially.– The schedule specifies an order for conflicting operations.

• Any two schedules for {T,S,...} that order the conflicting operations in the same way are equivalent.

• A schedule for {T,S,...} is serializable if it is equivalent to some serial schedule on {T,S,...}.

• There may be other serializable schedules on {T,S,...} that do not meet this condition, but if we enforce this condition we are safe.

• Conflict serializability: detect conflicting operations and enforce a serial-equivalent order.

Legal Interleaved schedule1. avoid lost update problem

• T: transfer $100 from A to C: R(A) W(A) R(C) W(C)

• S: transfer $100 from B to C: R(B) W(B) R(C) W(C)

2. avoid inconsistent retrievals problem • T: transfer $100 from A to C: R(A) W(A) R(C) W(C)

• S: compute total balance for A and C: R(A) R(C)

3. avoid non-repeatable reads

T: transfer $100 from A to C R(A) W(A) R(C) W(C)

S: check balance and withdraw $100 from A: R(A) R(A) W(A)

Defining legal schedule• . To be serializable, the conflicting operations of T and S must be

ordered as if either T or S had executed first.• We only care about the conflicting operations:

everything else will take care of itself.• 2. Suppose T and S conflict over some shared item(s) x.• 3. In a serial schedule, T’s operations on x would appear before S’s,

or vice versa....for every shared item x.• As it turns out, this is true for all the operations, but

again, we only care about the conflicting ones.• 4. A legal (conflict-serializable) interleaved schedule of T and S must

exhibit the same property.• Either T or S “wins” in the race to x; serializability

dictates that the “winner take all”.