Outline - Buisness Management - Lecture Slides, Slides of Business Administration

Download Outline - Buisness Management - Lecture Slides and more Slides Business Administration in PDF only on Docsity!

Outline

1. The Basics

2. ACID Properties

3. Atomicity and Two-Phase Commit

4. Performance

5. Styles of System

Docsity.com

1.2 The ACID Properties

• Transactions have 4 main properties
  • Atomicity - all or nothing
  • Consistency - preserve database integrity
  • Isolation - execute as if they were run alone
  • Durability - results aren’t lost by a failure

Docsity.com

Atomicity

• All-or-nothing, no partial results.
  • E.g. in a money transfer, debit one account, credit the other. Either debit and credit both run, or neither runs.
  • Successful completion is called Commit.
  • Transaction failure is called Abort.
• Commit and abort are irrevocable actions.
• An Abort undoes operations that already executed
  • For database operations, restore the data’s previous value from before the transaction
  • But some real world operations are not undoable. Examples - transfer money, print ticket, fire missile Docsity.com

Example - ATM Dispenses Money

(a non-undoable operation)

T1: Start

... Commit Dispense Money

T1: Start

... Dispense Money Commit

System crashes

Deferred operation never gets executed

System crashes Transaction aborts Money is dispensed

Docsity.com

Reading Uncommitted Output Isn’t

Undoable

T1: Start ... Display output ... If error, Abort

T2: Start Get input from display ... Commit

User reads output … User enters input Brain transport

Docsity.com

Compensating Transactions

• A transaction that reverses the effect of another transaction (that committed). For example, - “Adjustment” in a financial system - Annul a marriage
• Not all transactions have complete compensations
  • E.g. Certain money transfers
  • E.g. Fire missile, cancel contract
  • Contract law talks a lot about appropriate compensations

 A well-designed TP application should have a compensation for every transaction type Docsity.com

Consistency

Every transaction should maintain DB consistency

• Referential integrity - E.g. each order references an existing customer number and existing part numbers
• The books balance (debits = credits, assets = liabilities)

 Consistency preservation is a property of a transaction, not of the TP system (unlike the A, I, and D of ACID)

• If each transaction maintains consistency, then serial executions of transactions do too.

Docsity.com

Some Notation

• ri[x] = Read(x) by transaction Ti
• w (^) i[x] = Write(x) by transaction Ti
• c (^) i = Commit by transaction Ti
• a (^) i = Abort by transaction Ti
• A history is a sequence of such operations, in the order that the database system processed them.

Docsity.com

Consistency Preservation Example

T 1 : Start; A = Read(x); A = A - 1; Write(y, A); Commit;

T 2 : Start; B = Read(x); C = Read(y); If (B > C+1) then B = B - 1; Write(x, B); Commit;

• Consistency predicate is x > y.
• Serial executions preserve consistency. Interleaved executions may not.
• H = r 1 [x] r 2 [x] r 2 [y] w 2 [x] w 1 [y]
  • e.g. try it with x=4 and y=2 initially Docsity.com

Isolation

• Intuitively, the effect of a set of transactions should be the same as if they ran independently
• Formally, an interleaved execution of transactions is serializable if its effect is equivalent to a serial one.
• Implies a user view where the system runs each user’s transaction stand-alone.
• Of course, transactions in fact run with lots of concurrency, to use device parallelism.

Docsity.com

A Serializability Example

T 1 : Start; A = Read(x); A = A + 1; Write(x, A); Commit;

T 2 : Start; B = Read(x); B = B + 1; Write(y, B); Commit;

• H = r 1 [x] r 2 [x] w 1 [x] c 1 w 2 [y] c (^2)
• H is equivalent to executing T 2 followed by T (^1)
• Note, H is not equivalent to T 1 followed by T (^2)
• Also, note that T 1 started before T 2 and finished before T 2 , yet the effect is that T 2 ran first. Docsity.com