DOC PREVIEW
Berkeley COMPSCI 186 - Transaction Management Overview

This preview shows page 1 out of 4 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Transaction Management OverviewR & G Chapter16There are three side effects of acid.Enhanced long term memory,decreased short term memory,and I forget the third.- Timothy LearyConcurrency Control & Recovery• Concurrency Control– Provide correct and highly available data access inthe presence of concurrent access by many users• Recovery– Ensures database is fault tolerant, and notcorrupted by software, system or media failure– 24x7 access to mission critical data• A boon to application authors!– Existence of CC&R allows applications be bewritten without explicit concern for concurrencyand fault toleranceRoadmap• Overview (Today)• Concurrency Control (1-2lectures)• Recovery (1-2 lectures)Query Optimizationand ExecutionRelational OperatorsFiles and Access MethodsBuffer ManagementDisk Space ManagementDBThese layers mustconsider concurrencycontrol and recovery(Transaction, Lock,Recovery Managers)Structure of a DBMSTransactions and ConcurrentExecution• Transaction (“xact”)- DBMS’s abstract view of a userprogram (or activity):– A sequence of reads and writes of database objects.– Unit of work that must commit or abort as an atomic unit• Transaction Manager controls the execution oftransactions.• User’s program logic is invisible to DBMS!– Arbitrary computation possible on data fetched from the DB– The DBMS only sees data read/written from/to the DB.• Challenge: provide atomic transactions to concurrentusers!– Given only the read/write interface.Concurrency: Why bother?• The latency argument• The throughput argument• Both are critical!ACID properties of TransactionExecutions••AA tomicity: All actions in the Xact happen, or nonehappen.••CC onsistency: If each Xact is consistent, and the DBstarts consistent, it ends up consistent.••II solation: Execution of one Xact is isolated from thatof other Xacts.••DD urability: If a Xact commits, its effects persist.Atomicity and Durability• A transaction ends in one of two ways:–commit after completing all its actions• “commit” is a contract with the caller of the DB–abort (or be aborted by the DBMS) after executing someactions.• Or system crash while the xact is in progress; treat as abort.• Two important properties for a transaction:–Atomicity : Either execute all its actions, or none of them–Durability : The effects of a committed xact must survivefailures.• DBMS ensures the above by logging all actions:–Undo the actions of aborted/failed transactions.–Redo actions of committed transactions not yetpropagated to disk when system crashes.A.C.I.D.Transaction Consistency• Transactions preserve DB consistency– Given a consistent DB state, produce anotherconsistent DB state• DB Consistency expressed as a set of declarativeIntegrity Constraints– CREATE TABLE/ASSERTION statements• E.g. Each CS186 student can only register in one project group.Each group must have 2 students.– Application-level• E.g. Bank account total of each customer must stay the sameduring a “transfer” from savings to checking account• Transactions that violate ICs are aborted– That’s all the DBMS can automatically check!A.C.I.D.Isolation (Concurrency)• DBMS interleaves actions of many xacts concurrently– Actions = reads/writes of DB objects• DBMS ensures xacts do not “step onto” one another.• Each xact executes as if it were running by itself.– Concurrent accesses have no effect on a Transaction’sbehavior– Net effect must be identical to executing all transactionsfor some serial order.– Users & programmers think about transactions in isolation• Without considering effects of other concurrent transactions!A.C.I.D.Example• Consider two transactions (Xacts):T1: BEGIN A=A+100, B=B-100 ENDT2: BEGIN A=1.06*A, B=1.06*B END• 1st xact transfers $100 from B’s account to A’s• 2nd credits both accounts with 6% interest.• Assume at first A and B each have $1000. What are thelegal outcomes of running T1 and T2?• T1 ; T2 (A=1166,B=954)• T2 ; T1 (A=1160,B=960)• In either case, A+B = $2000 *1.06 = $2120• There is no guarantee that T1 will execute before T2 orvice-versa, if both are submitted together.Example (Contd.)• Consider a possible interleaved schedule:T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B This is OK (same as T1;T2). But what about:T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B• Result: A=1166, B=960; A+B = 2126, bank loses $6 !• The DBMS’s view of the second schedule:T1: R(A), W(A), R(B), W(B)T2: R(A), W(A), R(B), W(B)Scheduling Transactions:Definitions•Serial schedule: no concurrency– Does not interleave the actions of different transactions.•Equivalent schedules: same result on any DB state– For any database state, the effect (on the set of objects inthe database) of executing the first schedule is identical tothe effect of executing the second schedule.•Serializable schedule: equivalent to a serial schedule– A schedule that is equivalent to some serial execution of thetransactions.(Note: If each transaction preserves consistency,every serializable schedule preserves consistency. )Anomalies with Interleaved Execution• Reading Uncommitted Data (WR Conflicts,“dirty reads”):• Unrepeatable Reads (RW Conflicts):T1: R(A), W(A), R(B), W(B), AbortT2: R(A), W(A), CT1: R(A), R(A), W(A), CT2: R(A), W(A), CAnomalies (Continued)• Overwriting Uncommitted Data (WWConflicts):T1: W(A), W(B), CT2: W(A), W(B), CLock-Based Concurrency Control• A simple mechanism to allow concurrency but avoidthe anomalies just described…•Two-phase Locking (2PL) Protocol:– Always obtain a S (shared) lock on object before reading– Always obtain an X (exclusive) lock on object before writing.– If an Xact holds an X lock on an object, no other Xact can get a lock (Sor X) on that object.– DBMS internally enforces the above locking protocol– Two phases: acquiring locks, and releasing them• No lock is ever acquired after one has been released• “Growing phase” followed by “shrinking phase”.• Lock Manager tracks lock requests, grants locks on databaseobjects when they become available. Strict 2PL• 2PL allows only serializable schedules but issubjected to cascading aborts.• Example: rollback of T1 requires rollback ofT2!• To avoid Cascading aborts, use Strict 2PL• Strict Two-phase Locking (Strict


View Full Document

Berkeley COMPSCI 186 - Transaction Management Overview

Documents in this Course
Load more
Download Transaction Management Overview
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Transaction Management Overview and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Transaction Management Overview 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?