{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

transaction - T RAN SACT I ON S R ECOVERY C ON CU RREN CY...

Info iconThis preview shows pages 1–9. Sign up to view the full content.

View Full Document Right Arrow Icon
TRANSACTIONS, RECOVERY & CONCURRENCY CONTROL (Ch 17, 18, 19) Yi Chen Dept of Computer Science & Engineering Arizona State University
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
CSE 412/598 2 Outline Transaction - ACID properties Recovery – System Log Immediate updates Deferred updates Concurrency Control Schedule of multiple transactions Serializability Locking  2 mechanisms to ensure serializability 2PL Time stamps
Background image of page 2
CSE 412/598 3 TRANSACTI ON An  atomic  (all  or  nothing)  program  unit  that  performs  database  access  or  update,  taking  a  consistent  (correct)  database  state  into  another consistent database state.    database is consistent here     begin transaction; /* Transfer funds */ balance1   balance1 - amount    database is inconsistent here balance2   balance2 + amount    end transaction; /* Transfer funds */     database is consistent here      ACID properties of a transaction     Atomicity, Consistency, Isolation, Durability
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
CSE 412/598 4 ATOMI CI TY  “The system under test must guarantee that transactions are atomic; the  system will either perform all individual operations on the data, or will assure  that  no  partially completed  operations  leave  any  effects  on  the  data.”  [TPCA89]   e.g. ATM WITHDRAWAL (amt)   read bal if bal > amt { bal   bal - amt /* system goes down */ dispense money } [TPCA89] TPC BENCHMARK TM  A Standard Specification, 10 November 1989
Background image of page 4
CSE 412/598 5 CONSI STENCY   “Consistency is the property that requires any execution of the  transaction to take the database from one consistent state to another.” [TPCA89]  Since the assumption is that a transaction is written so that it is consistent,  consistency  means  that  it  remains  consistent  in  the  presence  of  the  concurrent execution of transactions (Serializability) (more on this later)  e.g.  ATM WITHDRAWAL (amt1)      ATM WITHDRAWAL (amt2) read bal if bal > amt1 read bal { if bal > amt2 bal   bal - amt1 { dispense money bal   bal - amt2 } dispense money }
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
CSE 412/598 6 I SOLATI ON   The  transaction  should  not  reveal  its  uncommitted  results  to    other  transactions ...    e.g.  ATM WITHDRAWAL (amt1) ATM WITHDRAWAL (amt2) read bal if bal > amt1 { bal  <-  bal  -  amt1 read bal /* trans aborted */ if bal > amt2 dispense money { } bal   bal  -  amt2 dispense money }
Background image of page 6
CSE 412/598 7 DURABI LI TY  “The test bed system must guarantee the ability to preserve the  effects  of  committed  transactions  and  insure  database  consistency  after recovery” from single failures... [TPCA89]  system crash/hang requiring system reboot  memory failure (all or part) Next we discuss how to ensure ACID.
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
CSE 412/598 8 Outline
Background image of page 8
Image of page 9
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}