lecture15 - Transactions Transactions Fundamentals of...

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

View Full Document Right Arrow Icon
Transactions Transactions Fundamentals of Database Systems: ch 17 Database System Concepts: ch 15
Background image of page 1

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

View Full DocumentRight Arrow Icon
Overview Overview Transaction : A sequence of database actions enclosed within special tags Properties: A tomicity : Entire transaction or nothing C onsistency : Transaction, executed completely, takes database from one consistent state to another I solation : Concurrent transactions appear to run in isolation D urability : Effects of committed transactions are not lost Consistency: Transaction programmer needs to guarantee that DBMS can do a few things, e.g., enforce constraints on the data Rest: DBMS guarantees
Background image of page 2
How How Relate to queries that we discussed ? Queries don’t update data, so durability and consistency not relevant Would want concurrency Consider a query computing total balance at the end of the day Would want isolation What if somebody makes a transfer while we are computing the balance Typically not guaranteed for such long-running queries
Background image of page 3

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

View Full DocumentRight Arrow Icon
Assumptions and Goals Assumptions and Goals Assumptions: The system can crash at any time Similarly, the power can go out at any point Contents of the main memory won’t survive a crash, or power outage Disks are durable. They might stop, but data is not lost. Disks only guarantee atomic sector writes, nothing more Transactions are by themselves consistent Goals: Guaranteed durability, atomicity As much concurrency as possible, while not compromising isolation and/or consistency Two transactions updating the same account balance… NO Two transactions updating different account balances… YES
Background image of page 4
Next Next States of a transaction A simple solution called shadow copy Satisfies Atomicity, Durability, and Consistency, but no Concurrency Very inefficient
Background image of page 5

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

View Full DocumentRight Arrow Icon
Transaction states Transaction states
Background image of page 6
Shadow Copy Shadow Copy Make updates on a copy of the database. Switch pointers atomically after done. Some text editors work this way
Background image of page 7

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

View Full DocumentRight Arrow Icon
Shadow Copy Shadow Copy Atomicity: As long as the DB pointer switch is atomic. Okay if DB pointer is in a single block Concurrency: No. Isolation: No concurrency, so isolation is guaranteed. Durability: Assuming disk is durable (we will assume this for now). Very inefficient: Databases tend to be very large. Making extra copies not feasible. Further, no concurrency.
Background image of page 8
Next Concurrency control schemes A CC scheme is used to guarantee that concurrency does not lead to problems For now, we will assume durability is not a problem No crashes Though transactions may still abort Schedules When is concurrency okay ? Serial schedules
Background image of page 9

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

View Full DocumentRight Arrow Icon
Image of page 10
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 39

lecture15 - Transactions Transactions Fundamentals of...

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

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