04/22/23 1

Transaction Processing

04/22/23 2

Transactions

• Many enterprises use databases to store information about their state– e.g., Balances of all depositors at a bank

• When an event occurs in the real world that changes the state of the enterprise, a program is executed to change the database state in a corresponding way– e.g., Bank balance must be updated when deposit is made

• Such a program is called a transaction

04/22/23 3

What Does a Transaction Do?• Update the database to reflect the

occurrence of a real world event– Deposit transaction: Update customer’s balance

in database • Cause the occurrence of a real world event

– Withdraw transaction: Dispense cash (and update customer’s balance in database)

• Return information from the database– RequestBalance transaction: Outputs customer’s

balance

04/22/23 4

Transactions• The execution of each transaction must maintain the

relationship between the database state and the enterprise state

• Therefore additional requirements are placed on the execution of transactions beyond those placed on ordinary programs:– Atomicity– Consistency– Isolation– Durability ACID

properties

04/22/23 5

ACID Properties• Atomic - Transaction should either complete or have no effect

at all – Responsibility of transaction processing system

• Consistent - Transaction should correctly transform the database state to reflect the effect of a real world event – Responsibility of transaction designer

• Isolation - The effect of concurrently executing a set of transactions is the same as if they had executed serially (serializable) – Responsibility of transaction processing system

• Durable - The effect of a transaction on the database state should not be lost once the transaction has committed – Responsibility of transaction processing system

04/22/23 6

Database Consistency• Enterprise (Business) Rules limit the occurrence

of certain real-world events– Student cannot register for a course if the current

number of registrants equals the maximum allowed• These limitations are (static) integrity

constraints: assertions that must be satisfied by the database state

• Database is consistent if all static integrity constraints are satisfied

04/22/23 7

Transaction Consistency• A consistent database state does not necessarily model

the actual state of the enterprise– A deposit transaction that increments the balance by the

wrong amount maintains the integrity constraint balance 0, but does not maintain the relation between the enterprise and database states

• A consistent transaction maintains database consistency and the correspondence between the database state and the enterprise state (implements its specification)– Specification of deposit transaction includes

balance = balance + amt_deposit , (balance is the initial value of balance)

04/22/23 8

Atomicity• A real-world event either happens or does

not happen– Student either registers or does not register

• Similarly, the system must ensure that either the corresponding transaction runs to completion or, if not, it has no effect at all– Not true of ordinary programs. A crash could

leave files partially updated on recovery

04/22/23 9

Commit and Abort

• If the transaction successfully completes it is said to commit– The system is responsible for preserving the

transaction’s results in spite of subsequent failures• If the transaction does not successfully complete,

it is said to abort– The system is responsible for undoing, or rolling back,

any changes the transaction has made

04/22/23 10

Reasons for Abort

• System crash• Transaction aborted by system

– Execution cannot be made atomic (a site is down)– Execution did not maintain database consistency

(integrity constraint is violated)– Execution was not isolated– Resources not available (deadlock)

• Transaction requests to roll back

04/22/23 11

API for Transactions• DBMS provide commands for setting transaction

boundaries. For example:– begin transaction– commit– rollback

• The commit command is a request– The system might commit the transaction, or it might

abort it for one of the reasons on the previous slide• The rollback command is always satisfied

04/22/23 12

Durability• Durability deals with failure:

– Media failure• The system must ensure that once a transaction

commits, its effect on the database state is not lost in spite of subsequent failures– Not true of ordinary programs. A media failure after a

program successfully terminates could cause the file system to be restored to a state that preceded the program’s execution

• Mechanism for dealing with failures is the log

04/22/23 13

Isolation• Serial Execution: The transactions execute one

after the other– Each one starts after the previous one completes.– The execution of each transaction is isolated from all

others.• Serial execution is inadequate from a performance

perspective• Concurrent execution offers performance benefits:

– A computer system has multiple resources capable of executing independently (e.g., cpu’s, I/O devices),

– only concurrently executing transactions can make effective use of the system

04/22/23 14

Concurrent Execution

04/22/23 15

Isolation• Concurrent (interleaved) execution of a set of

consistent transactions offers performance benefits, but might not be correct

• Example: course registration; cur_reg is number of current registrants

T1: r(cur_reg : 29) w(cur_reg : 30)T2: r(cur_reg : 29) w(cur_reg : 30) time Result: Database state no longer corresponds toreal-world state, integrity constraint violated(cur_reg <> |list_of_registered_students|)

04/22/23 16

Transaction Schedule

• Consistent - performs correctly when executed in isolation starting in a consistent database state– Preserves database consistency– Moves database to a new state that corresponds to new real-

world state

T1: begin_transaction(); …. p1,1;

….

p1,2;

…. p1,3; commit();

localvariables

Transaction schedule p1,3 p1,2 p1,1

To dbserver

04/22/23 17

Schedule

T1

T2

T3transactionschedules

Concurrency Control

Arriving schedule(merge of transactionschedules)

Schedule in whichrequests are serviced

To database

Database server

04/22/23 18

Example Schedules• Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from A to B. The following is a

serial schedule, in which T1 is followed by T2.

Schedule 1

04/22/23 19

Example Schedule (Cont.)• Let T1 and T2 be the transactions defined previously. The following schedule

is not a serial schedule, but it is equivalent to the previous Schedule.

In both Schedule 1 and 2, the sum A + B is preserved.

Schedule 2

04/22/23 20

Example Schedules (Cont.)• The following concurrent schedule does not preserve the value of the sum A + B.

Schedule 3

04/22/23 21

Correct Schedules

• Interleaved schedules equivalent to serial schedules are the only ones guaranteed to be correct for all applications

• Equivalence based on commutativity of operations• Definition: Database operations p1 and p2

commute if, for all initial database states, they return the same results and leave the database in the same final state when executed in either order.

04/22/23 22

Commutativity of Read and Write Operations

• p1 commutes with p2 if– They operate on different data items

• w1(x) commutes with w2(y) and r2(y)

– Both are reads• r1(x) commutes with r2(x)

• Operations that do not commute conflict• w1(x) conflicts with w2(x)

• w1(x) conflicts with r2(x)

04/22/23 23

Equivalence of Schedules• An interchange of adjacent operations of

different transactions in a schedule creates an equivalent schedule if the operations commute S1 : S1,1, pi,j, pk,l, S1,2 where i < > k S2 : S1,1, pk,l, pi,j, S1,2

• Equivalence is transitive: If S1 can be derived from S2 by a series of such interchanges, S1 is equivalent to S2

04/22/23 24

Example of EquivalenceS1: r1(x) r2(x) w2(x) r1(y) w1(y)

S2: r1(x) r2(x) r1(y) w2(x) w1(y)

S3: r1(x) r1(y) r2(x) w2(x) w1(y)

S4: r1(x) r1(y) r2(x) w1(y) w2(x)

S5: r1(x) r1(y) w1(y) r2(x) w2(x)S1 is equivalent to S5 S5 is the serial schedule T1, T2 S1 is serializable S1 is not equivalent to the serial schedule T2, T1

conflict

conflicting operationsordered in same way

04/22/23 25

Example of EquivalenceT1: begin transaction read (x, X); X = X+4; write (x, X); commit;

T2: begin transaction read (x,Y); write (y,Y); commit;

r1(x) r2(x) w2(y) w1(x)x=1, y=3 x=5, y=1 x=5, y=1 r2(x) w2(y) r1(x) w1(x) T2 T1

r1(x) r2(x) w2(y) w1(x)x=1, y=3 x=5, y=1 x=5, y=5 r1(x) w1(x) r2(x) w2(y) T1 T2

Interchange commuting operations

Interchangeconflicting operations

04/22/23 26

Serializable Schedules

• S is serializable if it is equivalent to a serial schedule

• Transactions are totally isolated in a serializable schedule

• A schedule is correct for any application if it is a serializable schedule of consistent transactions

• The schedule :r1(x) r2(y) w2(x) w1(y)

is not serializable

04/22/23 27

Serializability

• Different forms of schedule equivalence give rise to the notions of:1. Conflict serializability2. View serializability

04/22/23 28

Conflict Serializability• Two schedules are conflict equivalent if:

– they have the same sets of actions, and– each pair of conflicting actions is ordered in the same

way.• A schedule is conflict serializable if it is conflict

equivalent to a serial schedule.– Note: Some serializable schedules are not conflict

serializable!

04/22/23 29

Conflict Serializability (Cont.)• Schedule 2 below can be transformed into Schedule 1, a serial

schedule where T2 follows T1, by series of swaps of non-conflicting instructions. Therefore Schedule 2 is conflict serializable.

04/22/23 30

Conflict Serializability (Cont.)• Example of a schedule that is not conflict serializable:

T3 T4

read(Q) write(Q)

write(Q)

We are unable to swap instructions in the above schedule to obtain either the serial schedule < T3, T4 >, or the serial schedule < T4, T3 >.

04/22/23 31

Precedence Graph

• A Precedence (or Serializability) graph:– Node for each Xact.– Arc from Ti to Tj if an action of Ti precedes and conflicts with an

action of Tj.

• T1 transfers $100 from A to B, T2 adds 6%– R1(A), W1(A), R2(A), W2(A), R2(B), W2(B), R1(B), W1(B)

T1 T2

04/22/23 32

Precedence Graph of a Schedule, S

• Theorem - A schedule is conflict serializable if and only if its precedence graph has no cycles

• If precedence graph is acyclic, the serializability order can be obtained by a topological sorting of the graph. This is a linear order consistent with the partial order of the graph.

04/22/23 33

Example

T1

T2

T3

T4

T5 T6 T7

T1

T2

T3

T4

T5 T6 T7

S is serializable in orderT1 T2 T3 T4 T5 T6 T7

S is not serializable due to cycle T2 T6 T7 T2

S: … p1,i, …, p2,j, ...

Conflict (*)

*

04/22/23 34

Example Schedule (Schedule A)T1 T2 T3 T4 T5

read(X)read(Y)read(Z)read(V)read(W)read(W)read(Y)write(Y)write(Z)read(U)read(Y)write(Y)read(Z)write(Z)read(U)write(U)

04/22/23 35

Precedence Graph for Schedule A

T3T4

T1 T2

A serializability order for Schedule A would beT5 T1 T3 T2 T4 .

04/22/23 36

Concurrency Control vs. Serializability Tests

• Testing a schedule for serializability after it has executed is a little too late!

• Goal – to develop concurrency control protocols that will assure serializability. They will generally not examine the precedence graph as it is being created; instead a protocol will impose a discipline that avoids nonseralizable schedules.

• Tests for serializability help understand why a concurrency control protocol is correct.

04/22/23 37

Concurrency Control

• Concurrency control cannot see entire schedule:– It sees one request at a time and must decide whether to

allow it to be serviced• Strategy: Do not service a request if:

– It violates strictness or serializability, or – There is a possibility that a subsequent arrival might

cause a violation of serializability

Concurrency ControlArriving schedule

(from transactions)

Serializable schedule

(to processing engine)

04/22/23 38

Locking: A Technique for C. C.

• A transaction can read a database item if it holds a read (shared) lock on the item

• It can read or update the item if it holds a write (exclusive) lock

• If the transaction does not already hold the required lock, a lock request is automatically made as part of the access

04/22/23 39

Locking

• Concurrency control usually done via locking.• Lock info maintained by a “lock manager”:

– Stores (XID, RID, Mode) triples. • This is a simplistic view; suffices for now.

– Mode {S,X}– Lock compatibility table:

• If a Xact can’t get a lock, it is suspended on a wait queue.

-- S X--SX

04/22/23 40

Two-Phase Locking (2PL)

• 2PL:– If T wants to read an object, first obtains an S lock.– If T wants to modify an object, first obtains X lock.– If T releases any lock, it can acquire no new locks!

• Locks are automatically obtained by DBMS.• Guarantees serializability!

– Why?

Time

# oflocks

lock point

growing phase

shrinking phase

04/22/23 41

Strict 2PL

• Strict 2PL:– If T wants to read an object, first obtains an S lock.– If T wants to modify an object, first obtains X lock.– Hold all locks until end of transaction.

• Guarantees serializability, and recoverable schedule, too!

Time

# oflocks

04/22/23 42

Lock Management

• Lock and unlock requests are handled by the lock manager• Lock table entry:

– Number of transactions currently holding a lock– Type of lock held (shared or exclusive)– Pointer to queue of lock requests

• Locking and unlocking have to be atomic operations• Lock upgrade: transaction that holds a shared lock can be

upgraded to hold an exclusive lock

04/22/23 43

Lock Manager Implementation

• Question 1: What are we locking?– Tuples, pages, or tables?– Finer granularity increases concurrency, but also increases locking

overhead.

• Question 2: How do you “lock” something??• Lock Table: A hash table of Lock Entries.

– Lock Entry:• OID• Mode• List: Xacts holding lock• List: Wait Queue

04/22/23 44

Handling a Lock Request

Lock Request (XID, OID, Mode)

Currently Locked?

Grant Lock

Empty Wait Queue?

Currently X-locked?

Mode==X Mode==S

No

YesNo Yes

Put on QueueYes

No

04/22/23 45

More Lock Manager Logic

• On lock release (OID, XID):– Update list of Xacts holding lock.– Examine head of wait queue.– If Xact there can run, add it to list of Xacts holding lock (change

mode as needed).– Repeat until head of wait queue cannot be run.

• Note: Lock request handled atomically!– via latches (i.e. semaphores/mutex; OS stuff).

04/22/23 46

Lock Upgrades

• Think about this scenario:– T1 locks A in S mode, T2 requests X lock on A, T3 requests S lock on A.

What should we do?

• In contrast: – T1 locks A in S mode, T2 requests X lock on A, T1 requests X lock on A.

What should we do?

• Allow such upgrades to supersede lock requests.– Consider this scenario:

• S1(A), X2(A), X1(A): DEADLOCK! • BTW: Deadlock can occur even w/o upgrades:

– X1(A), X2(B), S1(B), S2(A)

04/22/23 47

Deadlocks

• Deadlock: Cycle of transactions waiting for locks to be released by each other.

• Two ways of dealing with deadlocks:– Deadlock prevention– Deadlock detection

04/22/23 48

Deadlock Prevention

• Assign a timestamp to each Xact as it enters the system. “Older” Xacts have priority.

• Assume Ti requests a lock, but Tj holds a conflicting lock.– Wait-Die: If Ti has higher priority, it waits; else Ti

aborts. (non-preemptive)– Wound-Wait: If Ti has higher priority, abort Tj; else Ti

waits. (preemptive)– Note: After abort, restart with original timestamp!– Both guarantee deadlock-free behavior! Pros and cons

of each?

X1(A), X2(B), S1(B), S2(A)

04/22/23 49

Deadlock Detection

• Create a waits-for graph:– Nodes are transactions– There is an edge from Ti to Tj if Ti is waiting for Tj to

release a lock• Periodically check for cycles in the waits-for graph.• “Shoot” some Xact to break the cycle.• Simpler hack: time-outs.

– T1 made no progress for a while? Shoot it.

04/22/23 50

Deadlock Detection (Continued)

Example:

T1: S(A), R(A), S(B)T2: X(B),W(B) X(C)T3: S(C), R(C) X(A)T4: X(B)

T1 T2

T4 T3

T1 T2

T3 T3

04/22/23 51

Prevention vs. Detection

• Prevention might abort too many Xacts.• Detection might allow deadlocks to tie up resources for a

while.– Can detect more often, but it’s time-consuming.

• The usual answer:– Detection is the winner.– Deadlocks are pretty rare.– If you get a lot of deadlocks, reconsider your schema/workload!

04/22/23 52

Exercise

• Determine whether each of following executions is serializable or not. For each serializable execution, give the serial schedule which is equivalent to the given schedule.

1. R1(X), W2(X), W1(X), R2(Y)

2. R1(X), W2(X), W3(X), R1(X)

3. R1(X), W2(X), W3(Y), W1(Y)

04/22/23 53

Exercise• Transactions T1, T2, T3 are to be run concurrently. The following

gives details of the proposed interleaving of read/write operations and the time when each such operation is to be scheduled.

Time T1 T2 T31 read(A)2 read(A)3 read(D)4 write(D)5 write(A)6 read(C)7 write(B)8 write(B)• Determine whether the operations can be executed in this order if

concurrency is to be controlled using two-phase locking