Computer Science 425Distributed

Systems

Computer Science 425Distributed

Systems

Lecture 21

Transaction Processing and Concurrency Control

Reading: Sections 13.1-13.2

AcknowledgementAcknowledgement

• The slides during this semester are based on ideas and material from the following sources:

– Slides prepared by Professors M. Harandi, J. Hou, I. Gupta, N. Vaidya, Y-Ch. Hu, S. Mitra.

– Slides from Professor S. Gosh’s course at University o Iowa.

Administrative Administrative

• MP2 posted October 5, 2009, on the course website,

– Deadline November 6 (Friday)

– Demonstration, 4-6pm, 11/6/2009

– Sign Up for demonstrations – Friday 4-6pm in 216 SC

Banking transaction for a customer (ATM)Transfer $100 from saving to checking account;

Transfer $200 from money-market to checking account;

Withdraw $400 from checking account.

Transaction:1. savings.deduct(100) /* includes verification */

2. checking.add(100) /* depends on success of 1 */

3. mnymkt.deduct(200) /* includes verification */

4. checking.add(200) /* depends on success of 3 */

5. checking.deduct(400) /* includes verification */

6. dispense(400)

7. commit

Example TransactionExample Transaction

Client ServerTransaction

Transaction Transaction Sequence of operations that forms a single step,

transforming the server data from one consistent state to another.

All or nothing principle: a transaction either completes successfully, and the effects are recorded in the objects, or it has no effect at all. (multiple clients, or crashes)

Transactions’ operations are indivisible (atomic) from the point of view of other transactions

No access to intermediate results/states

Free from interference by other operations

But…

Transactions could run concurrently

Transactions may be distributed

Transaction:1. savings.deduct(100)

2. checking.add(100)

3. mnymkt.deduct(200)

4. checking.add(200)

5. checking.deduct(400)

6. dispense(400)

7. commit

Transaction Failure Modes Transaction Failure Modes

A failure at these points means the customer loses money; we need to restore

A failure at these points does not cause lost money, but the transaction cannot be repeated

This is the point of no return

A failure after the commit point (ATM crashes) needs corrective action; no undoing possible.

Properties of Transactions (ACID) Properties of Transactions (ACID) Atomicity: All or nothing

Consistency: starting in a consistent state, the transaction ends in a consistent state.

Isolation: Each transaction must be performed without interference from other transactions, i.e., the non-final effects of a transaction must not be visible to other transactions.

Durability: After a transaction has completed successfully, all its effects are saved in permanent storage.Data saved in a file will survive if the server process crashes.

“To support failure atomicity and durability, objects must be recoverable”

Atomicity: store tentative object updates (for later undo/redo)

Durability: store entire results of transactions (all updated objects) to recover from permanent server crashes.

Bank Server: Coordinator InterfaceBank Server: Coordinator Interface

Transactions are managed by a coordinator:openTransaction() -> trans;

starts a new transaction and delivers a unique transaction identifier (TID) trans. This TID will be used in the other operations in the transaction.

closeTransaction(trans) -> (commit, abort);ends a transaction: a commit return value indicates that the transaction has committed; an abort return value indicates that it has aborted.

abortTransaction(trans);aborts the transaction.

TID can be passed implicitly (for other operations between open and close) with CORBA

Transactions are achieved by cooperation between client process, the server, the coordinator, and recoverable objects.

Transactions can be implemented using RPCs/RMIs!

Bank Server: Account, Branch interfacesBank Server: Account, Branch interfaces

deposit(amount)deposit amount in the account

withdraw(amount)withdraw amount from the account

getBalance() -> amountreturn the balance of the account

setBalance(amount)set the balance of the account to amount

create(name) -> accountcreate a new account with a given name

lookup(name) -> account return a reference to the account with the given name

branchTotal() -> amountreturn the total of all the balances at the branch

Operations of the Branch interface

Operations of the Account interface

ACID - IsolationACID - Isolation

Concurrent Transactions: Lost Update ProblemConcurrent Transactions: Lost Update Problem One transaction causes loss of info. for another:

consider three account objects

Transaction T1 Transaction T2

balance = b.getBalance()

balance = b.getBalance()

b.setBalance(balance*1.1)

b.setBalance = (balance*1.1)

a.withdraw(balance* 0.1)

c.withdraw(balance*0.1)

T1/T2’s update on the shared object, “b”, is lost

100 200 300a: b: c:

280c:

80a:

220b:

220b:

Conc. Trans.: Inconsistent Retrieval Prob.Conc. Trans.: Inconsistent Retrieval Prob. Partial, incomplete results of one transaction are

retrieved by another transaction.

Transaction T1 Transaction T2

a.withdraw(100)

total = a.getBalance()

total = total + b.getBalance

b.deposit(100)

total = total + c.getBalance

T1’s partial result is used by T2, giving the wrong result

100 200

0.00

a: b:

00a:

500

200

300c:

total

300b:

An interleaving of the operations of 2 or more transactions is said to be serially equivalent if the combined effect is the same as if these transactions had been performed sequentially (in some order).

Transaction T1 Transaction T2 balance = b.getBalance()

b.setBalance = (balance*1.1)

balance = b.getBalance()

b.setBalance(balance*1.1)

a.withdraw(balance* 0.1)

c.withdraw(balance*0.1)

Concurrency Control: “Serial Equivalence”Concurrency Control: “Serial Equivalence”

100 200 300a: b: c:

278c:

a:

242b:

b: 220

80

== T1 (complete) followedby T2 (complete)

An interleaving of the operations of 2 or more transactions is said to be serially equivalent if the combined effect is the same as if these transactions had been performed sequentially (in some order).

Transaction T1 Transaction T2 balance = b.getBalance()

b.setBalance = (balance*1.1)

balance = b.getBalance()

b.setBalance(balance*1.1)

a.withdraw(balance* 0.1)

c.withdraw(balance*0.1)

Concurrency Control: “Serial Equivalence”Concurrency Control: “Serial Equivalence”

100 200 300a: b: c:

278c:

a:

242b:

b: 220

80

== T1 (complete) followedby T2 (complete)

Pairs of Conflicting Operations

Two operations are in conflict, if their combined effect depends on the order they are executed, e.g., read-write, write-read, write-write (NOT read-read)The effect of an operation refers to

The value of an object set by a write operation

The result returned by a read operation.

Two transactions are serially equivalent if and only if all pairs of conflicting operations (pair containing one operation from each transaction) are executed in the same order (transaction order) for all objects (data) they both access.Why? Can start from original operation sequence and swap the order of

non-conflicting operations to obtain a series of operations where one transaction finishes completely before the second transaction starts

Why is the above result important? Because: Serial equivalence is the basis for concurrency control protocols for transactions.

Conflicting Operations Conflicting Operations

Read and Write Operation Conflict RulesRead and Write Operation Conflict Rules

Operations of differenttransactions

Conflict Reason

read read No Because the effect of a pair of read operations

does not depend on the order in which they are

executed

read write Yes Because the effect of a read and a write operation

depends on the order of their execution

write write Yes Because the effect of a pair of write operations

depends on the order of their execution

Conflicting Operators Example Conflicting Operators Example Transaction T1 Transaction T2

x= a.read()

a.write(20) y = b.read()

b.write(30)

b.write(x)

z = a.read()

x= a.read()

a.write(20) z = a.read()

b.write(x)

y = b.read()

b.write(30)

Serially equivalent interleaving of operations

(why?)

Conflicting Ops.

Non-serially equivalent interleaving of operations

Inconsistent Retrievals ProblemInconsistent Retrievals Problem

Transaction V :

a.withdraw(100)

b.deposit(100)

Transaction W:

aBranch.branchTotal()

a.withdraw(100); $100

total = a.getBalance() $100

total = total+b.getBalance() $300

total = total+c.getBalance()

b.deposit(100) $300

Both withdraw and deposit contain a write operation

A Serially Equivalent Interleaving of V and WA Serially Equivalent Interleaving of V and W

Transaction V : a.withdraw(100);b.deposit(100)

Transaction W :

aBranch.branchTotal()

a.withdraw(100); $100

b.deposit(100)$300

total = a.getBalance() $100

total = total+b.getBalance() $400

total = total+c.getBalance()...

ACID – AtomicAll or NothingACID – AtomicAll or Nothing

A Dirty Read When Transaction T AbortsA Dirty Read When Transaction T Aborts

Transaction T:

a.getBalance()a.setBalance(balance + 10)

Transaction U:

a.getBalance()a.setBalance(balance + 20)

balance = a.getBalance() $100

a.setBalance(balance + 10) $110

balance = a.getBalance() $110

a.setBalance(balance + 20) $130

commit transaction

abort transaction

• Transaction U here encounters a dirty read from another transaction that aborts.

How to avoid dirty readsHow to avoid dirty reads

• Two ways to avoid dirty reads (at run-time):

1. U could delay running the conflicting operation (e.g., a.getBalance()) until T commits or aborts

2. U delays its commit until after T commits. In that case, if T aborts, then U aborts as well.

• Rule (2) allows more concurrency than rule (1).

• However, rule (2) above could lead to cascading aborts (T aborts, then U aborts, then another transaction V that dirty read from U aborts, and so on…)

• To avoid cascading aborts, restrict transactions to read only objects that were written by committed transactions, i.e., rule (1).

Premature WritesPremature Writes

Transaction T:

a.setBalance(105)

Transaction U:

a.setBalance(110)

$100

a.setBalance(105) $105

a.setBalance(110) $110

• Suppose the action of abort is implemented by restoring “before images” of all the writes of the transaction.

Premature WritesPremature Writes

Transaction T:

a.setBalance(105)

Transaction U:

a.setBalance(110)

$100

a.setBalance(105) $105

a.setBalance(110) $110

• Suppose the action of abort is implemented by restoring “before images” of all the writes of the transaction. The before image of T’s write is $100. The before image of U’s write is $105. If T commits and U aborts $105 (ok) If U commits then T aborts $100 (not ok - $110 would be the correct value) If T aborts then U aborts $105 (not ok - $100 would be the correct value) If U aborts then T aborts $100 (ok)• Write operations must be delayed until other transactions that updated the same objects earlier have either committed or aborted, i.e., U delays a.setBalance() until T has committed or aborted

Banking transaction for a customer (ATM)Transfer $100 from saving to checking account;

Transfer $200 from money-market to checking account;

Withdraw $400 from checking account.

Transaction:1. savings.deduct(100) /* includes verification */

2. checking.add(100) /* depends on success of 1 */

3. mnymkt.deduct(200) /* includes verification */

4. checking.add(200) /* depends on success of 3 */

5. checking.deduct(400) /* includes verification */

6. dispense(400)

7. commit

Example Transaction – Need Concurrency ControlExample Transaction – Need Concurrency Control

Transaction Processing Systems Transaction Processing Systems

Client

Client

Client

Client

Client

Trans. Manager

Object Manager

Scheduler

Trans. Manager

Object Manager

Scheduler

Concurrency Control

• Transaction Workspace• locking / unlocking req.• Protocol management• Subtrans Management

Object Creation, lock

recovery, destruction

Objects

Objects

Network

SummarySummary

• Transactions an important concept• ACID properties• Serial Equivalence and Conflicting Operations• Ensuring the aborts do not violate ACID