computer science 328 distributed systems
Download
Skip this Video
Download Presentation
Computer Science 328 Distributed Systems

Loading in 2 Seconds...

play fullscreen
1 / 22

lect-10 - PowerPoint PPT Presentation


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

Computer Science 328Distributed Systems

Lecture 10

Transaction Processing

transactions
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
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
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
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
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
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
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
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
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
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

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

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

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

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

:

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

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

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

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

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