Distributed Software Develop - Distributed Transactions | CS 682, Study notes of Software Engineering

Download Distributed Software Develop - Distributed Transactions | CS 682 and more Study notes Software Engineering in PDF only on Docsity!

Distributed Software Development

Distributed Transactions

Chris Brooks

Department of Computer Science

University of San Francisco

Department of Computer Science — University of San Francisco – p. 1/

Transactions

Features of transactions

Serial equivalence

Locking and deadlock

Distributed transactions

Two-phase commit

Distributed deadlock

Department of Computer Science — University of San Francisco – p. 2/

Example

As an example, we’ll look at an interface to a bankingsystem.

We’d like to be able to do the following operations onaccounts:

deposit(amt)

withdraw(amt)

getBalance()

setBalance(amt)

We’d also like the following operations to be availablefor branches:

CreateAccount(name)

lookUpAccount(name)

totalAccounts()

Department of Computer Science — University of San Francisco – p. 4/

Example transaction

A transaction may involve several operations, each ofwhich changes the state of a different object:

Transaction T:

1. alexAcct.withdraw(100)2. nancyAcct.deposit(100)3. nancyAcct.widthdraw(200)4. brooksAcct.deposit(200)

We can’t stop in the middle, lose any of theoperations, or do them in the wrong order.

Department of Computer Science — University of San Francisco – p. 5/

ACID

The desirable features of a transactional DBMS aresometimes referred to as ACID

Atomicity

Consistency

Isolation

Durability

Department of Computer Science — University of San Francisco – p. 7/

Atomicity

Atomicity is sometimes referred to as “all-or-nothing”.

Either a transaction completes successfully, and alleffects are applied to all objects, or it has no effect atall.

Either all withdraws and deposits are made, or noneof them are.

Department of Computer Science — University of San Francisco – p. 8/

Isolation

The intermediate effects of a transaction must not bevisible to other transactions.

In our example, Nancy’s bank account balancebriefly went up by $100. (the money was thentransferred to Brooks’ account)

No other process or transaction should see thatbalance.

In other words, to the outside world, a transactionmust appear as a single operation.

Department of Computer Science — University of San Francisco – p. 10/

Isolation

How to provide isolation?

Perform all transactions in a single thread

Works, but doesn’t scale.

Use locks to control concurrent access.

Better, although now we need to detect (and undo)deadlocks.

Department of Computer Science — University of San Francisco – p. 11/

Common problems in transaction

processing

If we assume that a server will process multipletransaction simultaneously (in separate threads),problems can occur.

Lost updates

Inconsistent retrievals

Department of Computer Science — University of San Francisco – p. 13/

Lost updates

’Lost updates’ refer to the problem of one transactionoverwriting the result of another transaction.

For example:

Consider transactions T and U. T wants to transfer 10% of the balance in accountB from A to B. U wants to transfer 10% of the balance in account B from C to B. Bstarts at $200.

Transaction T:^ •

balance1 = B.getBalance()

B.setBalance(balance1 * 1.1)

A.withdraw(balance1 / 10)

Transaction U:^ •

balance2 = B.getBalance()

B.setBalance(balance2 * 1.1)

C.withdraw(balance1 / 10)

Department of Computer Science — University of San Francisco – p. 14/

Inconsistent retrievals

Consider transaction T: transfer $100 from account Ato B. Transaction U: get branchTotal():

Transaction T:

A.withdraw(100)

B.deposit(100)

Transaction U:

getBranchTotal()

Department of Computer Science — University of San Francisco – p. 16/

Inconsistent retrievals

If the operations are performed in this order, we getan inconsistent retrieval:

(T) A.withdraw(100)

(U) getBranchTotal()

(T) B.deposit(100)

The bank’s total will appear to be $100 less than itshould.

Department of Computer Science — University of San Francisco – p. 17/

Conflicting operations

The trick to achieving serial equivalence is to identifyoperations that conflict with each other.

Read/write and write/write (read/read is OK)

For two transactions to be serially equivalent, allpairs of conflicting operations must be executed inthe same order on all objects they both access.

Department of Computer Science — University of San Francisco – p. 19/

Conflicting operations

For example:

T: x=read(i); write(i,10); write(j,20)

U: read(j); write(j,30); z=read(i)

To have serial equivalence, one of the followingconditions must hold:

T accesses i before U does and T accesses jbefore U does

U accesses I before T does and U accesses Jbefore T does

Department of Computer Science — University of San Francisco – p. 20/