CS411 - Transaction Management - Note 1 - 2

Also transaction to be atomic because concurrent

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: //en.wikipedia.org/wiki/ACID Question: How do we recover our system when things go wrong? Recovery Recovery (0 of 8) Transaction Management (24 of 61) Application can be buggy, MySQL may have bugs, windows can go wrong, and disk can also have problems. Programmers can also be buggy. Q: What Might Go Wrong? Tornadoes in Champaign → store data in California( another place ) Disk Failure: Can be resolved by redundancy of disks, RAID, or Hadoop, etc. Recovery (1 of 8) Transaction Management (25 of 61) What should we do if things go wrong? We can lose everything stored in memory. System Failures • Each transaction has internal state • When system crashes, internal state is lost • Don’t know which parts executed and which didn’t • Remedy: use a log • A file that records every single action of the transaction Recovery (2 of 8) Transaction Management (26 of 61) Data stored in memory may be lost when operating system crashes, we need to only worry about data in the main memory. Things may not always get saved! Solution: Use a log file to keep track of every transaction Ways to start and end a transaction: Transactions • • Start Transaction • Oracle • autocommit is off by default, so a new transaction is started after each COMMIT or ROLLBACK • MySQL • • START TRANSACTION • End Transaction • COMMIT or ROLLBACK Commit: Things are done, and making sure that things are safely applied. Rollback: Remove the cache (abort all changes) and go back to the previous state. Recovery (3 of 8) Transaction Management (27 of 61) Transaction Abstraction • Database is composed of elements • Usually 1 element = 1 block • Can be smaller (=1 record) or larger (=1 relation) • Each transaction reads/writes some elements We only care about the changes we are going to make on the table, and we only care about elements. Element can be considered as a block. In each transaction we only care about the reads and writes(the value on the disk) Recovery (4 of 8) Transaction Management (28 of 61) Correctness Principle Notions of correctness for database • There exists a notion of correctness for the database o o • Explicit constraints (e.g. foreign keys) • Implicit conditions (e.g. sum of sales = sum of invoices) • Correctness principle: Transaction will be programmed such that: if a transaction starts in a correct database state, it ends in a correct database state. • Consequence: we only need to guarantee that transactions are atomic, and run (as if) in isolation. Recovery (5 of 8) Explicit constraints Implicit constraints...
View Full Document

This note was uploaded on 01/28/2014 for the course CS 411 taught by Professor Staff during the Fall '08 term at University of Illinois, Urbana Champaign.

Ask a homework question - tutors are online