Spring 2004 ECE569 Lecture ECE 569 Database System Engineering Spring 2004 Transaction Models Yanyong Zhang Course URL

Spring 2004 ECE569 Lecture Atomicity  Means you get the specified result or nothing at all  Does not mean that code is executed in such a way that it cannot be interrupted.  Defined only from the perspective of the caller of the operation.  Absolute atomic actions are impossible!

Spring 2004 ECE569 Lecture Disk Writes as Atomic Actions  Single disk write: Not an atomic operation l Blocks can be half-written l Blocks can be corrupted during transfer l Blocks can be written to the wrong address. l Neither all nor nothing  Read-after-write l First issue a single disk write, then rereads the block from disk and compares the result with the original block. l If the two are not identical, the sequence of writing and rereading is repeated until the block is successfully written. l If the block is bad, then this protocol does not help.

Spring 2004 ECE569 Lecture Disk Writes as Atomic Actions  Duplexed write l Each block has a version number, which is increased upon each invocation of the operation. l Each block is written to two places, A and B. First, a single disk write is done to A; after this operation is successfully completed, a single disk write is done to B. l Upon reading, the block is first read from position A; if this operation is successful, it is assumed to be the most recent, valid version of the block. If reading from A fails, then B is read. l This protocol increases the atomicity level if we assume single failure at a time.

Spring 2004 ECE569 Lecture Disk Writes as Atomic Actions  Logged writes l The old contents of the block are first read and then written to a different place (on a different storage device), using the single disk write operation. l The block is modified, and eventually a single disk write is performed to the old location. l To protect against unreported transient errors, the read- after-write technique could be used. l The log can be discarded if the block is successfully written.

Spring 2004 ECE569 Lecture A Classification of Action Types  Unprotected actions l These actions lack all of the acid properties except for consistency. l Unprotected actions are not atomic, and their effects cannot be depended upon.  Protected actions l Do not externalize their results before they are completely done. l Their updates can be rolled back if anything goes wrong l Once they have reached their normal end, there will be no unilateral rollback.  Real actions l Affect the physical world in a way that is hard or impossible to reverse. l Difficult to make them appear atomic, because the option of rollback does not exist.

Spring 2004 ECE569 Lecture The ACID Properties of Flat Transactions  Atomicity l For a transaction to be atomic, it must behave atomically to any outside ‘‘observer”.  Consistency l A transaction produces consistent results only; otherwise it aborts. l A result is consistent if the new state of the database fulfills all the consistency constraints of the application. l Do not have time to check them all (even if we knew what they are). If the program has functioned according to specification we assume it preserves consistency.

Spring 2004 ECE569 Lecture The ACID Properties of Flat Transactions  Isolation l Must behave exactly as it would in single-user mode. l Based on observable behavior from the outside, rather than on what is going on inside.  Durability l Durability requires that results of transactions having completed successfully must not be forgotten by the system l Once the system has acknowledged the execution of a transaction, it must be able to reestablish its results after any type of subsequent failure, whether caused by the user, the environment, or the hardware components.

Spring 2004 ECE569 Lecture Flat Transaction  Simplest type of transaction  It is the only supported model at application programming model  It can contain an arbitrary number of simple actions. These actions could be unprotected, protected, or real.  These transactions are flat because there is only one layer of control by the application.  The major restriction is that there is no way of either committing or aborting parts of such transactions, or committing results in several steps.

Spring 2004 ECE569 Lecture A Sample Transaction Program  This transaction is basis for the TPC-A and TPC-B transaction processing benchmarks. exec sql BEGIN DECLARE SECTION; long Aid, Bid, Tid, delta, Abalance; exec sql END DECLARE SECTION; DCApplication(){ read input msg; exec sql BEGIN WORK; Abalance = DoDebitCredit(Bid, Tid, Aid,delta); send output msg; exec sql COMMIT WORK; }

Spring 2004 ECE569 Lecture A Sample Transaction Program (cont’d) longDoDebitCredit(long Bid, long Tid, long Aid, long delta){ exec sql UPDATE accounts SETAbalance = Abalance + :delta WHEREAid = :Aid; exec sql SELECT Abalance INTO :Abalance FROM accountsWHERE Aid = :Aid; exec sql UPDATE tellers SETTbalance = Tbalance + :delta WHERE Tid = :Tid; exec sql UPDATE branches SETBbalance = Bbalance + :delta WHERE Bid = :Bid; exec sql INSERT INTO history(Tid, Bid, Aid, delta, time) VALUES (:Tid,:Bid,:Aid,:delta,CURRENT); return(Abalance); }

Spring 2004 ECE569 Lecture Limitations of Flat Transactions  Example - Travel Agent l Consider a travel agent booking airline and hotels for a trip to Ripa, Italy. -BEGIN WORK -S1:book flight from San Francisco to Frankfurt -S2:book flight from Frankfurt to Milan, same day -S3:book flight from Milan to Pisa, same day l Problem: No way to get to Ripa from Pisa the same day. With flat transaction model, the agent only has 2 choices: -Rollback entire transaction and redo parts of plan that work -Commit. Then issue a new transaction to cancel the reservation between Milan to Pisa.

Spring 2004 ECE569 Lecture Limitations of Flat Transactions (cont’d)  Example: Bulk Update l Add interest earned to every account in Bank ComputeInterest(){ exec sqlBEGIN WORK; exec sqlUPDATE checking_accounts SET account_balance = account_balance*(1+interest_rate); exec sqlCOMMIT WORK; }; l Updates every transaction in context of one transaction -Transaction will run for a long time -If transaction fails all of its work must be undone -May be just as well to remember what was done and continue from that point to finish.