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

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

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

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

Next Next  States of a transaction  A simple solution called shadow copy  Satisfies Atomicity, Durability, and Consistency, but no Concurrency  Very inefficient

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

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.

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

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