Computer science 328 distributed systems
Download
1 / 22

lect-10 - PowerPoint PPT Presentation


  • 274 Views
  • Uploaded on

Computer Science 328 Distributed Systems Lecture 10 Transaction Processing Transactions Sequences of operations that forms a single step, transforming the server data from one consistent state to another.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'lect-10' - JasminFlorian


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Computer science 328 distributed systems l.jpg

Computer Science 328Distributed Systems

Lecture 10

Transaction Processing


Transactions l.jpg
Transactions

  • Sequences 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.

  • Transactions’ operations are indivisible from the point of view of other transactions

    • No access to intermediate results/states

    • Free from interference by other operations

  • Transactions may be distributed

  • Transactions could run concurrently


Example transaction l.jpg
Example Transaction

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. commit

7. dispense(400)


Transaction failure modes l.jpg
Transaction Failure Modes

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

A failure at these points means the customer looses money, we need to restore

Transaction:

1. savings.deduct(100)

2. checking.add(100)

3. mnymkt.deduct(200)

4. checking.add(200)

5. checking.deduct(400)

6. commit

7. dispense(400)

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

This is the point of no return


Properties of transactions acid l.jpg
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 intermediate 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”


Operations in coordinator interface l.jpg
Operations in Coordinator Interface

  • Transactions are managed by a coordinator:

  • openTransaction() -> trans;

    • starts a new transaction and delivers a unique TID trans. This identifier 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 with RMI

  • Transactions are achieved by cooperation between client program, the coordinator, and recoverable objects.


Operations of the account interface l.jpg
Operations of the Account interface

Operations of the Account interface

  • deposit(amount)

    • deposit amount in the account

  • withdraw(amount)

    • withdraw amount from the account

  • getBalance() -> amount

    • return the balance of the account

  • setBalance(amount)

    • set the balance of the account to amount

Operations of the Branch interface

  • create(name) -> account

    • create a new account with a given name

  • lookUp(name) -> account

    • return a reference to the account with the given name

  • branchTotal() -> amount

    • return the total of all the balances at the branch


Concurrency control lost update l.jpg
Concurrency Control: Lost Update

200

300

100

b:

c:

a:

  • 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)

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

220

b:

220

b:

80

a:

280

c:


Concurrency control inconsistent retrieval l.jpg
Concurrency Control: Inconsistent Retrieval

200

300

100

b:

c:

a:

  • 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

00

a:

total

0.00

200

300

b:

500


Serial equivalence l.jpg
Serial Equivalence

  • 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.

    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)

200

300

100

b:

c:

a:

220

b:

242

b:

80

a:

278

c:


Conflicting operations l.jpg
Conflicting Operations

  • Two operations are in conflict, if their combined effect depends on the order they are executed.

    • 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, iff all pairs of conflicting operations are executed in the same order for all objects (data) they both access.

  • Serial equivalence is the basis for concurrency control protocols for transactions.


Read and write operation conflict rules l.jpg

Operations of different

Conflict

Reason

transactions

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

Read and Write Operation Conflict Rules


Conflicting operators example l.jpg

Non-serially equivalent interleaving of operations

Conflicting Ops.

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


Serially equivalent interleaving of t and u l.jpg

Transaction

T

:

Transaction

U

:

balance = b.getBalance()

balance = b.getBalance()

b.setBalance(balance*1.1)

b.setBalance(balance*1.1)

a.withdraw(balance/10)

c.withdraw(balance/10)

balance = b.getBalance()

$200

b.setBalance(balance*1.1)

$220

balance = b.getBalance()

$220

b.setBalance(balance*1.1)

$242

a.withdraw(balance/10)

$80

c.withdraw(balance/10)

$278

Serially equivalent interleaving of T and U

T always executes the first

operation of all three pairs of

conflicting operations


A serially equivalent interleaving of t and u l.jpg

Transaction

T

:

Transaction

U

:

balance = b.getBalance()

balance = b.getBalance()

b.setBalance(balance*1.1)

b.setBalance(balance*1.1)

a.withdraw(balance/10)

c.withdraw(balance/10)

balance = b.getBalance()

$200

b.setBalance(balance*1.1)

$220

balance = b.getBalance()

$220

b.setBalance(balance*1.1)

$242

a.withdraw(balance/10)

$80

c.withdraw(balance/10)

$278

A Serially Equivalent Interleaving of T and U


Inconsistent retrievals problem l.jpg

:

Transaction

V

:

Transaction

W

a.withdraw(100)

aBranch.branchTotal()

b.deposit(100)

a.withdraw(100);

$100

total = a.getBalance()

$100

total = total+b.getBalance()

$300

total = total+c.getBalance()

b.deposit(100)

$300

Inconsistent Retrievals Problem

Both withdraw and deposit contain a write operation


A serially equivalent interleaving of v and w l.jpg

Transaction

V

:

Transaction

W

:

a.withdraw(100);

aBranch.branchTotal()

b.deposit(100)

$100

a.withdraw(100);

$300

b.deposit(100)

$100

total = a.getBalance()

$400

total = total+b.getBalance()

total = total+c.getBalance()

...

A Serially Equivalent Interleaving of V and W


A dirty read when transaction t aborts l.jpg

Transaction

T

:

Transaction

U

:

a.getBalance()

a.getBalance()

a.setBalance(balance + 10)

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

A Dirty Read When Transaction T Aborts

  • Any transaction (like U) that may encounter a dirty read delays its commit operation.

  • U delays its commit until after T commits. In the case that T aborts, U aborts as well.

  • To avoid cascading aborts, transactions are only allowed to read objects that were written

  • committed transactions.


Overwriting uncommitted values l.jpg

Transaction

T

:

Transaction

U

:

a.setBalance(105)

a.setBalance(110)

$100

a.setBalance(105)

$105

a.setBalance(110)

$110

Overwriting Uncommitted Values

  • The action of abort is implemented by restoring “before images”

  • of all the Writes of a 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

  • If U commits and T aborts  $100 ($110 is the correct value)

  • If T aborts and U aborts  $105 ($100 is the correct value)

  • If U aborts and T aborts  $100

  • Write operations must be delayed until earlier transactions that

  • updated the same objects have either committed or aborted.


Nested transactions l.jpg
Nested Transactions

  • Transactions can be composed of other subtransactions

  • A subtransaction appears atomic to its parent, w.r.t failure and concurrent access.

  • Subtransactions on the same level can run concurrently, subject to serialization.

T: top-level Trans

T2: Subtrans.

T1: Subtrans.

T21: Subtrans.

T12: Subtrans.

T11: Subtrans.


Nested transactions commitment rules l.jpg
Nested Transactions Commitment Rules

  • A transaction can commit/abort only after all its children have completed.

  • A subtransaction decides to provisionally commit (PROV) or abort.

  • When a transaction aborts, all its children are also aborted.

  • When a subtransaction aborts, the parent can decide to abort or commit.

  • When the top-level trans. commits, all subtrans that have PROVed also commit.


Nested transactions22 l.jpg

T : top-level transaction

T

= openSubTransaction

T

= openSubTransaction

1

2

commit

T

:

T

:

1

2

openSubTransaction

openSubTransaction

openSubTransaction

prov. commit

abort

T

T

:

T

:

:

21

11

12

openSubTransaction

prov. commit

prov. commit

prov. commit

T

:

211

prov.commit

Nested transactions


ad