What is a Transaction?

Transcription

1 Fall Semester 204 CS 34 Distributed Information Systems Chapter 3: Transaction Management (in parts a recap from CS243 Databases) H. Schuldt What is a Transaction? A transaction is a set of logically corresponding operations Traditional database transactions consider read and/or write operations of database pages in a single database system Distributed transactions consider access to different database systems which has to be coordinated In a more general setting, operations can be arbitrary service calls (and not only reading/writing pages). Such operations are called semantically rich operations. These are implemented by successively implemented by simpler operations (finally by read/write operations) Transactions are based on a generic concept to encapsulate operations and to provide dedicated guarantees for sequences/sets of operations Execution guarantees: ACID Guarantees are provided by the runtime system, transparently for users/programmers Developers/users simply have to specify transaction boundaries (BOT = Begin-of-Transaction and EOT = End-of-Transaction) 3-2

2 Atomicity Transaction Properties A transaction is either executed completely ( commit ) or does not leave any effects (appears as if it had never been started), i.e., it is aborted ( rollback ). Transaction atomicity corresponds to an All-or-Nothing semantics. Consistency A transaction transfers one consistent database state into another consistent database state. Isolation Transactions, even when being executed in parallel, appear as if they were executed in isolation (i.e., sequentially) Durability After a transaction has committed, its effects are persistent (they even survive system crashes) 3-3 Enforcing ACID Properties Transactions can be considered as contract between the application program and the runtime system of the database ACID properties are the contents of this contract The most important tasks of a database system include The correct synchronization of concurrent transactions (Concurrency Control isolation) The correct treatment of system crashes and application failures (Recovery atomicity, persistence) For both areas, conventional transaction models consider dedicated correctness criteria dedicated components exist to enforce these guarantees 3-4 2

3 Transaction Management: Examples Example: Bank Transfer Traditional scenario for database transactions Short-living transactions, operate on few database objects Features parallel accesses to account table Account (AcctID, CustNo, BranchNo, Balance) Typical operations Debit (AcctID, Amount) Credit (AcctID, Amount) withdraws Amount from account AcctID credits Amount to account AcctID and Transfer (AcctID-A, AcctID-B, Amount), which consists of Debit (AcctID-A, Amount) and Credit (AcctID-B, Amount). 3-5 Bank Transfer: Scenario I want to withdraw 50.- CHF from my account I want to transfer CHF to the account of my grandchild Client Debit (47, 50.- CHF) DBMS Client Transfer (085, 47, CHF) = Debit (085, CHF) Credit (47, CHF) DB Bank 3-6 3

4 Bank Transfer: Atomicity I want to withdraw 50.- CHF from my account AcctID Balance I want to transfer CHF to the account of my grandchild SELECT balance INTO :balancetransa FROM Account WHERE acctid = 085;... fl Violation of all-or-nothing property (atomicity) since an inconsistent intermediate state survives t balancetransa := balancetransa - 200; UPDATE Account SET balance = :balancetransa WHERE acctid = 085; SELECT balance INTO :balancetransb FROM Account WHERE acctid = 47; AcctID Balance *** Program Crash *** Bank Transfer: Isolation I want to withdraw 50.- CHF from my account AcctID Balance I want to transfer CHF to the account of my grandchild SELECT balance INTO :balanceatm FROM Account WHERE AcctID = 47; balanceatm := balanceatm 50; UPDATE Account SET balance = :balanceatm WHERE AcctID = 47; t SELECT balance INTO :balancetransb FROM Account WHERE AcctID = 47; balancetransb := balancetransb + 200; UPDATE Account SET balance = :balancetransb WHERE AcctID = 47; 70.- AcctID Balance fl Both transactions do interfere in an inconsistent way 3-8 4

5 2. Read/Write Model Database (DB) Set of objects: DB = {o, o 2, } (for instance: database pages) Operation (OP) Set of operations: OP = {read, write} Action Action a є (OP DB), i.e., either read(o i ) or write(o i ). When considering semantically rich operations, this assumption will be generalized read(o i ) returns database object o i without having any side-effects write(o i ) changes database object o i Abbreviations: r(o i ) for read(o i ) w(o i ) for write(o i ) 3-9 Transaction Transaction (T) A transaction T is a tuple with T = ( ACT, < ) where ACT is a set of actions on which a (partial) order < is defined, i.e., ACT = { a, a 2,, a k }» term a,, a k are actions term œ {C, A} is a terminating action < (ACT ACT) is the precedence relation Each transaction T is terminated either by C (commit) or A (abort). C or A, respectively, are ordered after all other actions of a transaction with regard to <, i.e., a i < term for all i k. The precedence relation < specifies the execution order of all actions of a transaction. It can be < partial: allows for parallelisms within a transaction (intra-transactional parallelism) < total: sequential execution T = ( a < a 2 < < a k < C ) 3-0 5

6 Database System Model & Components A transaction manager (TM) accepts incoming read/write requests (of pages) and forwards them to the scheduler. In case of distributed databases, this also includes communication and coordination with remote transaction managers. The scheduler decides whether operations can be executed or whether they have to be deferred. The recovery manager (RM) protects the database from system failures (i.e., loss of transient storage) and guarantees persistence. The cache manager (CM) guarantees efficient data access. Transactions Transaction Manager (TM) Scheduler Recovery Manager (RM) read / write Database fetch / flush Cache Manager (CM) read / write / commit / abort read / write / commit / abort read / write / commit / abort flush fetch Log read / write DBMS Data Manager Cache transient Storage persistent Storage Serializability Theory Serializability addresses the correctness criteria for the correct execution of concurrent transactions. = { T, T 2,, T n } set of concurrent transactions that shall be executed correctly. Basic Assumption A: Each transaction T i is correct, when being executed in isolation. Basic Assumption A2: Each serial (sequential) execution of all n transactions (in any order) is correct. Different transactions are supposed to originate from different independent users/applications; for the latter, any sequential execution is acceptable. Needed: criteria that allow checking whether a given parallel execution is equivalent to such a serial execution! 3-2 6

7 a 2 2 a 2 n Schedule The parallel execution of all transactions in is reflected by a so-called schedule: Complete schedule S A complete schedule S is a triple S = (,, <). S contains the execution order of all actions of all transactions from in which all precedence relations are kept. with: = { T, T 2,, T n } set of transactions =» ACT i all actions of all transactions in (*) < ( ) partial order, with < i < for all T i (*) A complete schedule contains either exactly a C or an A for each transaction. 3-3 Schedule t T a 3 a 2 a T 2 a 2 T n a n Schedule: A schedule is a prefix of a complete schedule A schedule S contains Completed (C in S) Aborted (A in S) Active (neither C nor A in S) transactions. scheduler A complete schedule does not contain any active transactions. t a a n 2 a n a 2 schedule S 3-4 7

8 Schedule Serial schedule: In a serial schedule, < is total and for any i, k œ {,.., n}: all actions of T i are executed before all actions of T k S ser = a 2 a 22 C 2 a n a 2n C n a a 2 C n T 2 T n T Two serial schedules are considered correct usually return different database states. Committed projection: the committed projection C(S) of a schedules S is defined by removing all actions of transactions that have not committed yet C(S) neither contains active nor aborted transactions 3-5 Semantics of Actions The semantics of actions is defined as follows:: Read: Write: r i (x) reads object x from w k (x), where w k (x) is the last write action in S before r i (x). But: i k and T k is not aborted. w i (x) provides a new version of the object that replaces the old one. The write depends on all preceding readers of T i before w i (x). Ø The result of a write action thus depends (in an application-specific way) on all preceding read actions of the same transaction

9 Conflict Serializability Some actions within a schedule can be swapped without any changes (both for these actions and for the objects that are accessed). Example: r (x) < r 2 (x) ~ r 2 (x) < r (x) w (x) < w 2 (y) ~ w 2 (y) < w (x) Conversely, there are pairs of actions that cannot be swapped (as such a swap would have consequences on these actions and the objects they have accessed). In such cases, dependency relations exist. Example : r (x) < w 2 (x) w 2 (x) < r (x) w (x) < w 2 (x) w 2 (x) < w (x) 3-7 Conflict Relation Actions that cannot be swapped are considered to be in conflict. This is reflected in the conflict relation con. Conflict relation con: con(a, a ) ñ () a and a operate on the same DB object (2) a = read(x) a = write(x) r/w conflict a = write(x) a = read(x) w/r-conflict a = write(x) a = write(x) w/w-conflict In the read/write model, two actions are in conflict if they access the same DB object any of these two actions is a Write

10 Dependency Relation The dependency relation of a schedules S contains all conflict pairs of all transactions in S. Dependency & dependency relation: Let S be a schedule. Action a k is dependent on action a i in S, short: a i Ø a k ñ () i k T i and T k are different transactions, (2) a i <a k a i is before a k in S, (3) con(a i, a k ) a i and a k are in conflict, (4) C i, C k in S both transactions are completed (with commit). The dependency relation dep(s) is the set of all dependent pairs in S: dep(s) = {(a i, a k ) œ S a i Ø a k } Examples: S = w (a) r 2 (a) r (b) w 2 (b) C C 2 Ò dependent: w (a) Ø r 2 (a), r (b) Ø w 2 (b) dep(s ) = {(w (a), r 2 (a) ), (r (b), w 2 (b))} S = w (a) r (b) C r 2 (a) w 2 (b) C 2 Ò dependent: w (a) Ø r 2 (a), r (b) Ø w 2 (b) dep(s ) = {(w (a), r 2 (a) ), (r (b), w 2 (b))} 3-9 Conflict Equivalence The dependency relations allows to capture the semantics of a schedule and thus to compare two schedules over the same set of transactions. Conflict Equivalence: Two schedules S and S are conflict equivalent, if both schedules contain the same actions have an identical dependency relation, i.e., dep(s) = dep(s ) In case information flows between two transactions T i and T k, this can only happen via conflict pairs of T i and T k, thus via shared DB objects. Hence, the order of conflict pairs is essential for the direction of information flow. Example: S = w (a) r 2 (a) r (b) w 2 (b) C C 2 Ò S = w (a) r (b) C r 2 (a) w 2 (b) C 2 Ò S and S are conflict equivalent as dep(s ) = dep(s )

11 CPSR Conflict (preserving) serializability (CPSR): A schedule S is conflict serializable, if its committed projection C(S) is conflict equivalent to a serial schedule S ser. The class of all conflict serializable schedules is called CPSR. Conflict equivalent schedules can thus be produced by swapping actions that are not dependent. Observation: Since CPSR focuses on the committed projection of a schedule, the effect of aborted transitions is not considered. Example: S = w (a) r 2 (a) r (b) w 2 (b) C C 2 Ò S = w (a) r (b) C r 2 (a) w 2 (b) C 2 Ò S is CPSR, since S and S are conflict equivalent and since S is serial. 3-2 Swapping Actions In a serial execution, all actions of a transaction T i are executed before/after all actions of transaction T k. Example: S = a a 2 a 3 a 2 a 3 a 4 Ò if they are not in conflict ª a a 2 a 3 a 2 a 4 a 3 Ò if they are not in conflict ª a a 2 a 3 a 4 a 2 a 3 Ò finally, the schedule is serial Needed: a means to show the existence of a serial schedule that can be produced by swapping actions that are not in conflict. 3-22

12 Serializability Theorem Serialization Graph The serialization graph SG(S) of a schedule S is a graph for which the vertices are all transactions from S that have been committed the edges are all pairs (T i, T k ) for which holds: there are actions a i T i and a k in T k with (a i, a k ) dep(s). Example: S = r (a) r 2 (a) w 2 (a) r 3 (a) w 22 (b) w 23 (b) C C 2 C 3 Ò T 2 SG(S ) T T 3 A schedule S is conflict serializable (S œ CPSR) if its serialization graph SG(S) is free of cycles Examples S 2 = r (a) r 2 (a) w 22 (a) r 3 (a) w 2 (a) w 23 (a) C C 2 C 3 Ò SG(S 2 ) T 2 T T 3 SG(S 2 ) is not free of cycles T S 2 is not conflict serializable T there is no equivalent serial schedule

13 Order Preserving Serializability In CPSR, some (unexpected) artifacts may occur Example: S = r (x) r 2 (y) w 2 (y) r (y) C r 3 (z) C 3 r 2 (z) w 2 (z) C 2 Ò T2 T T 3 S in CPSR with serialization order: T 3 < T 2 < T But: the commit order is: T < T 3 < T 2 In particular, T is completely executed before T 3 starts; however, T 3 is serialized BEFORE T 3-25 OPSR Order preserving serializability: A schedule S is (transaction) order preserving serializable, if S œ CPSR and if there is at least one equivalent serial schedule S in which all completely ordered transactions in S have the same order in S. The class of order preserving serializable schedules is called OPSR. OPSR Õ CPSR Proof sketch: OPSR is subset of OPSR: immediate consequence of the above definition (each OPSR schedule is also in CPSR) OPSR ist a proper subset of CPSR: see example on previous slide

14 Commit Order Preservation OPSR simply addresses the preservation of the order of transactions that are completely ordered in a schedule (i.e., that are non-overlapping), but not the order in which commits take place. The latter is also addressed by commit order preservation serializability. Basic idea: make sure that parallel transactions are executed in a serializable way and provide a means to specify the serialization order. This is done via the order in which commits take place. Commit Order Preserving Serializability: A schedule S is commit order preserving serializable if the following holds for each pair T i, T k of committed transactions in S: if (a i, a k ) in dep(s), then C i < C k. The class of commit order preserving serializable schedules is called COPSR with COPSR Õ OPSR 3-27 Comparison of Correctness Criteria All schedules CPSR OPSR COPSR Serial schedules

15 t 2.3 Concurrency Control Protocols T a 3 a 2 a T 2 a 2 2 a 2 input schedule T n a 2 n a n The task of a scheduler is to transform an input schedule into a serializable output schedule A scheduler sch is thus a mapping Sch: ES # AS with ES being the set of all input schedules, AS the set of all serializable output schedules (i.e., AS ΠCPSR) t Scheduler (Sch) a a n 2 a n a 2 serializable schedule 3-29 Concurrency Control Protocols A concurrency control protocol is the protocol by which a scheduler enforces the output schedule to be serializable. In practice, only dynamic ( on-line ) schedulers are relevant. When an action a ik is to be executed, a concurrency control protocol can make the following decisions: Execute ak i Defer the execution of a k i (and execute it later) Abort transaction T k (a k i cannot be executed without violating the requirement of providing a serializable output schedule) These decisions can only be made on the basis of the prefix of a schedule, i.e., before a k i Depending on the type of concurrency control protocol, this decision is either made for actions on data objects (r(x) or w(x)), or for the terminating action (commit or abort). Only few protocols consider both types of actions. The off-line scheduling after analysis of all actions of all transactions in is in practice not feasible

16 Conservative vs. Optimistic Protocols Conservative Protocols A conservative scheduler checks prior to each action whether or not this action can be executed. A commit, in turn, is allowed at any time. Usually, conservative schedulers rely on locking protocols. These approaches expect conflicts to occur and thus set locks to prevent these conflicts to lead to non-serializable executions. Therefore, these approaches are also called pessimistic protocols. They allow individual actions to be deferred and thus to be swapped with other actions from the input schedule. Optimistic Protocols An optimistic scheduler permits each action to be immediately executed, without prior check whether this action would lead to a non-serializable schedule. Such approaches are also called aggressive protocols. However, optimistic scheduler have to add a validation phase prior to the transaction s commit in which conflicts are analyzed, in order to guarantee correctness. In practice, conservative approaches are much more widely used than optimistic protocols. 3-3 Two-Phase Locking (2PL) Main idea: Before an object is accessed (either in read or write mode), a lock has to be acquired. These locks have to make sure that no two conflicting actions can be executed on the same object. These locks have to be managed (acquired, checked, released) by the system in a way that is fully transparent to the application and/or user. Example: The transaction T = a a 2 a k Ò will be automatically transformed into: T * = L(a ) a L(a 2) a 2 L(a k) a k U(a )U(a 2) U(a k) Ò where L(a i k) acquires a lock on the object accessed by action a i k ( lock ) U(a i k) releases the lock held for a i k ( unlock )

17 Lock Modes The objective of the 2PL protocol is to avoid onflicting actions on the same object, but at the same time not to constrain actions that are not in conflict. Hence, two parallel transactions might read the same object, but only one is allowed to write (and then, no additional read is allowed). For this, two different lock modes are needed: S lock (= Shared Lock) for read access r(x) X lock (= Exclusive Lock) for write access w(x) For the two modes, the following lock compatibility matrix can be defined: Lock held Transaction acquires Shared exclusive Shared + exclusive + acquired lock can be granted (execution order of two readers can be changed; no conflict in case of r/r) acquired lock CANNOT be granted (because of w/r, r/w, or w/w-conflict). The requesting transaction has to wait) PL Protocol A scheduler follows the 2PL protocol if it: () acquires a (compatible) lock L(a i k) before each action a i k (L = shared when a i k is a read, otherwise: L = exclusive) (2) holds the lock L(a i k) at least until action a i k has been executed (3) after a lock is released, no other lock of the same transaction can be acquired. A 2PL scheduler only produces serializable (CPSR) schedules; actually, the resulting schedules of 2PL are even order-preserving serializable (OPSR). Number of Locks BOT EOT t expansion phase shrinking phase

18 Strict Two-Phase Locking (S2PL) Protocol A scheduler follows the strict two-phase locking (S2PL) protocol if it: () acquires a lock L(a i k) before each action a i k (S for reads, X for writes) (2) all locks L(a i k) are held until the end of its transaction (i.e., they will all be jointly released at commit time) Apparently, S2PL is stronger than 2PL. Hence, each S2PL protocol also guarantees serializable executions. In addition, each schedule produced by an S2PL scheduler is even commit-order preserving serializable (COPSR). Number of Locks The shrinking phase coincides with the transaction commit BOT EOT t 3-35 Example for 2PL Input schedule r (a) w 2 (a) w (b) C w 2 (b) C 2 Ò Lock table of the 2PL scheduler at different points in time t: time object t 0 t t 2 t 3 t 4 t 5 t 6 t 7 a (T, S) (T, S) (T, S) (T 2, X) (T 2, X) b (T, X) (T 2, X) Queue for lock acquisition T 2,a,X T 2,a,X T 2,a,X Lock requests/ releases of the scheduler L (a,s) L 2 (a,x) L (b,x) U (a) U (b) L 2 (a,x) L 2 (b,x) U2 (a) U 2 (b) t 0 t t 2 t 3 t 4 t 5 t 6 t 7 Output schedule r (a) w (b) C w 2 (a) w 2 (b) C 2 Ú t

19 Deadlocks An important drawback of 2PL and S2PL is the fact that cyclic wait dependencies may occur. This means that transactions wait (potentially infinitely long) on locks held by other transactions which, in turn, cannot be released (since the transaction that holds these locks also waits for lock requests to be granted. Such cyclic waiting dependencies are also called deadlock. Example: Input schedule ES ES = r (x) w 2 (y) w 2 (x) C 2 w (y) C Ò An S2PL scheduler produces the following output schedule S: S = L (x,s) r (x) L 2 (y,x) w 2 (y) Ò T 2 waits for a lock held by T (and cice versa); no transaction is able to proceed. Since both transations are not completed, no lock can be released fl both transactions would wait forever! 3-37 Deadlock Detection: Wait-For-Graph How can deadlocks be detected? For this, a dedicated data structure (wait-for-graph, WFG) is introduced. Nodes of this graph are transactins, edges T i Ø T k are added if and only if T i waits on a lock held by T k (T i waits for Unlock von T k ) Example: Input schedule ES: ES = r 3 (a) w (b) w (c) w (a) r 2 (d) w 2 (e) r 4 (b) w 2 (c) r 3 (e) r 5 (e) C 2 C 3 C 5 C C 4 Ò The production of an output schedule for ES with 2PL produces the following wait dependencies: WFG(S): T 3 T 2 T 4 T T

20 Deadlock Resolution Deadlocks corresponds to (one or many) cycle(s) in the wait-for graph. Hence, efficient algorithms are needed for detecting cycles in a directed graph. When (in what intervals) shall we activate cycle detection? Possible strategies are: Periodically, after a fixed time Before any new edge is added to the graph (continuously) Deadlocks can only be resolved by aborting transaction(s) from the WFG cycle (as these transactions cannot proceed anyways). However, this creates costs since the aborted transactions have already consumed resources. Aborted transactions have to be re-started by their users/application programs Deadlock Resolution Which transaction(s) shall be aborted (selection of a deadlock victim )? Possible strategies are: Last transaction that has added an edge to the WFG ( last blocked ) Transaction that holds the least number of locks ( minimum locks ) Transaction for which the least abort costs incur (i.e., the one that has issued the fewest update operations, minimum work ) Transaction that will resolve the most cycles ; this is particularly relevant when periodic checks are applied Transaction whose abort will remove most edges ) from the WGF

21 Lock Conversion Deadlocks can also occur due to lock conversion (when upgrading a shared lock into an exclusive lock) this occurs quite often in practice. Such type of deadlocks can be avoided by additional lock modes or when the user or application programmer explicitly intervenes. In SQL, this is possible in the form: SELECT * FROM WHERE FOR UPDATE This automatically sets an exclusive lock, even though the object is at least for the time being- only read. 3-4 Serialization Graph Test (SGT) The serialization graph test (SGT) approach is based on the very straightforward idea that a scheduler keeps a serialization graph and enforces it to be free of cycles. This of course guarantees the resulting schedule to be in CPSR. SGT algorithm: Preprequisite: the following infrmation is needed at any point in time A k : set of actions of all active and correctly completed transactions T k SG: the current serialization graph action p i of transaction T i is to be executed if T i is not yet in SG Insert node T i in SG for all T k, i.e., for all active and committed transactions Add edge T k Ø T i to SG, if there is an action q k in A k that is in conflict with p i. check whether SG is acyclic if yes: execute p i and insert p i into A i ; otherwise abort T i

22 2.4 Snapshot Isolation (SSI) So far, for each transaction T k we have only considered actions r k (x) and w k (x), respectively, as well as the termination of T k (commit C k or abort A k ). In order to formalize snapshot isolation (SSI), we need additional information for each transaction T k : Read Set RS(T k ): Set of database objects read by T k Write Set WS(T k ): Set of database objects written by T k Start of T k : BOT k (Begin-of-Transaction) Usually, BOT k is not specified explicitly; it is associated with the first action of T k. Moreover, SSI considers versions of objects. Each write w k produces a new version of an object w k (x k ), a reader selects one of the existing versions, e.g., r i (x k ) with w k (x k ) < r i (x k ) Snapshot Isolation: Definition Idea: Each transaction T k is assigned an individual version (snapshot) of the database at BOT. This snapshot is valid for the comlete lifetime of T k. Snapshot Isolation (SSI): A schedule is correct with regard to the Snapshot Isolation (SSI) criterion, if the following holds: (SSI-V) r k (x i ): w i (x i ) < C i < BOT k < r k (x i ) and ± w m (x m ) with: w m (x m ) < BOT k and C i < C m < BOT k (SSI-W) T i, T k with (BOT i < BOT k < C i ) (BOT k < BOT i < C k ) the following holds: WS(T i ) WS(T k ) = SSI-V: SSI-W: Assigns reach reader r k (x) the youngest value x i that of x has been committed at BOT k Any pair of concurrent (overlapping) transactions has disjoint Write Sets

23 SSI: Examples Example : S = r (x) r 2 (y) w 2(x) r 2 2(x) C 2 w 3(y) C Ò S CPSR When operating on snapshots: S = r (x 0 ) r 2 (y 0 ) w 2(x ) r 2 2(x 0 ) C 2 w 3(y ) C Ò S is serializable Checking SSI: (SSI-W): WS(T ) = {x,y}, WS(T 2 ) = fl WS(T ) WS(T 2 ) = (SSI-V): also respected fl S œ SSI Example 2: S 2 = r (x) r 2 (y) w 2 2(y) C 2 r 2(y) w 3(y) C Ò When operating on snapshots: S 2 = r (x 0 ) r 2 (y 0 ) w 2 2(y 2 ) C 2 r 2(y 2 ) w 3(y ) C Ò S 2 is serializable T 0 <T 2 <T Ò Checking SSI: (SSI-W): NOT supported, since WS(T ) = WS(T 2 ) = {y} (SSI-V): also not supported fl S 2 SSI SSI: Examples Example 3: S 3 = r (x) r 2 (y) r 2 2(x) r 2(y) w 2 3(x) w 3(y) C C 2 Ò When operating on snapshots: S 3 = r (x 0 ) r 2 (y 0 ) r 2 2(x 0 ) r 2(y 0 ) w 2 3(x 2 ) w 3(y ) C C 2 Ò Checking SSI: (SSI-W): WS(T ) = {y}, WS(T 2 ) = {x} fl WS(T ) WS(T 2 ) = (SSI-V): also supported fl S 3 œ SSI BUT: S 3 is not serializable as there is no equivalent serial execution. fl SSI allows schedules that do not have any equivalence to a serial schedule

24 Practical Example Tables Account Interest (AcctID, Balance, AcctHolder), (AcctID, InterestLevel) Transaction T (Determine Interest): Read Balance If < Balance < then increase InterestLevel by % If Balance > 0 000, increase InterestLevel by 2% Transaction T 2 (Receive Interest): Read specific account values Book Interest on Account Initial values for Account 47: Balance = 9999 InterestLevel = 3% 3-47 Practical Example Transaction T : > Select Balance from Account where AcctID = 47; Transaction T 2 : > Select InterestLevel from Interest where AcctID = 47; > Select Balance from Account where AcctID = 47; > Select InterestLevel from Interest where AcctID = 47; > Update Interest Set InterestLevel = InterestLevel + where AcctID = 47; > commit; t > Update Account set Balance= Balance*InterestLevel where AcctID = 47; > commit; S 3 = r (x) r 2 (y) r 2 2 (x) r 2 (y) w 2 3 (x) w 3 (y) C C 2 Ú

25 Practical Example S 3 is not serializable However, S 3 is correct with regard to SSI as both (SSI-V) and (SSI-W) are jointly supported! Both possible serial (and thus by definition correct) schedules lead to other results (either higher InterestLevel or higher Balance) T < T 2 : Balance = 0399 and InterestLevel = 4% T 2 < T : Balance = 0299 and InterestLevel = 5% Here: Balance = 0299 and InterestLevel = 4% SSI is being used (as strictest concurrency control protocol) some commercial and open source database systems (e.g., Oracle) Transaction Recovery Concurrency Control does not consider application failures, i.e., the side-effects of aborted transactions are ignored. CPSR only considers the committed projection of a schedule Hence, we have implicitly assumed that all actions of aborted transactions can be deleted Transaction recovery addresses the criteria that have to be fulfilled in order actually undo the effects of the write actions of aborted transactions in order to guarantee atomic behavior

26 Transaction Recovery Example I want to withdraw 50.- CHF from my account SELECT balance INTO :balanceatm FROM Account WHERE acctid = 47; AcctID Balance I want to transfer CHF to the account of my grandchild... SELECT balance INTO :balancetransb FROM Account WHERE acctid = 47; balancetransb := balancetransb + 200; Update Account SET balance = :balancetransb WHERE acctid = 47; balanceatm := balanceatm 50; Update Account SET balance = :balanceatm WHERE acctid = 47; COMMIT WORK; t ROLLBACK WORK; 3-5 Recoverability The atomicity property requires that the effects of aborted transactions are completely undone. This includes both changes that have already been applied in the database as well as effects on other transactions. However, the abort of a transaction can be impossible in situations where other, already committed transactions are affected: Example: S = w (x) r 2 (x) w 2 (y) C 2 A Ò Aborting transaction T in S cannot be done correctly as transaction T 2 has read from T and has already been committed. Hence, the effects of T cannot be completely undone

27 Recoverability (RC) The minimal requirement of schedules to correctly undo transactions is that each transaction T i can only commit after all transactions T k from which it has read. Reads-From: Let S be a schedule. r i (x) reads-from w k (x), i k, if: (a) w k (x) < r i (x) (b) w m (x) with w k (x) < w m (x) < r i (x) (c) T k is not aborted Reads-From-Relation: RF(S) = { (T k, x, T i ) r i (x) reads-from w k (x) in S} Recoverability (RC) A schedule S is recoverable, if the following holds for all transactions T i, T k in S: If (T k, x, T i ) œ RF(S) and i k and C i in S, then the commits have to be in the following order: C k < C i. All transactions T k, from which T i reads, have to be committed before T i. RC is the class of all recoverable schedules Example: Domino Effect I want to withdraw 50.- CHF from my account SELECT Balance INTO :balanceatm FROM Account WHERE AcctID = 47; AcctID Balance I want to transfer CHF to the account of my grandchild... SELECT Balance INTO :balancetransb FROM Account WHERE AcctID = 47; balancetransb := balancetransb + 200; Update Account SET Balance = :balancetransb WHERE AcctID = 47; balanceatm := balanceatm 50; Update Account SET Balance = :balanceatm WHERE AcctID = 47; ROLLBACK WORK; Transaction at the ATM must also be aborted! t

28 Avoiding Cascading Aborts (ACA) The effects we have seen in the previous example that might occur even in recoverable schedules are as follows: Example: S 2 = w (x) r 2 (x) w 2 (y) A Ò Since T 2 has read from T, the abort of T also implies the abort of T 2 (the object that has been read is no longer valid). The abort of single transactions might cascadingly lead to the abort of other transactions in an RC schedule. Avoiding Cascading Aborts (ACA) A schedule S avoids cascading aborts: if (T k, x, T i ) œ RF(S) and i k, then C k < r i (x). Transactions are only allowed to read committed values. The class of schedules that avoids cascading aborts is called ACA. ACA Õ RC: ACA is a proper subset ofrc Strictness For an abort of a transaction, all effects of its writes need to be undone. This is usually done by using the before image of the corresponding data object (i.e., the value the object had before it was modified by the aborted transaction). But this might not be correct if only ACA is provided: Example: S 3 = w (x) w 2 (x) C 2 A Ò S 3 is both in RC and ACA (as RF(S 3 ) = ). However, the before image of x which is used for undoing w (x) also indirectly undoes w 2 (x) of transaction T

29 Strictness (ST) Strictness (ST) A schedule S is strict, if the following holds: If w k (x) < a i (x) and i k in S, then termination actions need to be ordered as follows:: A k < a i (x) or C k < a i (x) (for a i œ {r i, w i }). An object may neither be read nor overwritten before it is commited or aborted. The class of strict schedules is called ST. ST Õ ACA: ST is a proper subset of ACA Rigorousness (RG) Rigorousness (RG) A schedule S ist rigorous, if there is either C i oder A i betwen each pair of conflicting actions a i < a k. The class of rigorous schedules is called RG. RG Õ ST: RG is a proper subset of ST

30 Discussion of Rigorousness RG avoids r/w, w/r and w/w conflicts between active transactions while ST does so only for w/r and w/w conflicts. This difference has significant practical consequences: RG Õ CPSR: RG is a proper subset of CPSR, the class of all conflict-serializable schedules. RG is the only correctness criterion that jointly guarantees correct concurrency control and recovery (yet in a very restrictive way): RG Õ (CPSR RC) Since RG requires the commits to be placed between pairs if conflicting actions, it is also included in COPSR (the class of commit-order preserving serializable schedules): RG Õ COPSR: RG is a proper subset of COPSR. In contrast to RG, the other criteria for correct recovery (ST, ACA and RC) are not comparable with CPSR, hence they do not also guarantee serializability Summary: Classes of Schedules RG Õ ST Õ ACA Õ RC and RG Õ COPSR All schedules CPSR RC ACA ST COPSR Serial schedules RG