8atomictrans - Introduction to Atomic Transactions Low...

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

View Full Document Right Arrow Icon
Introduction to Atomic Transactions Low level synchronization use semaphores for mutual exclusion, critical region management, deadlock prevention, and crash recovery. We want to have a high level abstraction for synchronization such that all of the above are hidden. We do have such abstraction and is called atomic transaction, or transaction, or atomic action. Atomic transaction = all-or-nothing One process wants to begin a transaction with one or more processes. They can negotiate various options, create and delete objects, and perform operations. Then the initiator announces that it want all the others to commit themselves to the work done so far. If all of them agree, the results are made permanent. If one or more processes refuse (or crash before agreement), the situation reverts to exactly the state it had before the transaction began, with all side effects on objects, files, databases, magically wiped out.
Background image of page 1

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

View Full DocumentRight Arrow Icon
Introduction to Atomic Transaction (continue) The idea of atomic transaction came from magnetic tapes (60s) If a run failed, all the tapes could be rewound & the job restarted with no harm done --- all-or-nothing property of an atomic transaction. Modern Banking example: Group the two operations together and form an atomic transaction Withdraw(amount, account1) Deposit(amount, account2) Crash between the steps: account1 debited, but account2 not credited So we want either both would be completed, or neither would be completed. The key is rolling back to the initial state if transaction fails. P r e v i o u s i n v e n t o r y T o d a y ' s u p d a t e s I B M 3 7 X X N e w i n v e n t o r y
Background image of page 2
The Transaction Model The system has some independent processes which can fail at random. Communication errors are handled transparently by underlying software. Stable Storage RAM is volatile, Disk survives CPU failures but not for disk head crashes. Stable storage is designed to survive anything except major disasters such as floods and earthquakes. Stable storage can be implemented with a pair of ordinary disks. (Figure 3-15) When two corresponding blocks differ, Disk1 is the correct one (Disk1 is updated first, then Disk2) When bad checksum is observed, copy from the corresponding block. a b d c a b d c a b’ d c a b d c a b d c a b d X Disk1 Disk2 bad checksum
Background image of page 3

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

View Full DocumentRight Arrow Icon
Transaction Primitives Programming using transactions requires special primitives that must either be supplied by the OS or the language run-time system. 1. BEGIN_TRANSACTION: Mark the start of a transaction. 3. ABORT_TRANSACTION: Kill the transaction; restore the old values.
Background image of page 4
Image of page 5
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 09/17/2009 for the course IT it771 taught by Professor Jenisha during the Fall '09 term at University of Advancing Technology.

Page1 / 13

8atomictrans - Introduction to Atomic Transactions Low...

This preview shows document pages 1 - 5. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online