Structuring Applications • Many applications involve long transactions Models of Transactions that make many database accesses • To deal with such complex applications many transaction processing systems Chapter 19 provide mechanisms for imposing some structure on transactions 2 Flat Transaction Flat Transaction • Consists of: begin transaction – Computation on local variables • Abort causes the begin transaction • not seen by DBMS; hence will be ignored in most future discussion execution of a program ¡£ ¤¦©¨ – Access to DBMS using call or ¢¡£ ¥¤§¦©¨ that restores the statement level interface variables updated by the ¡£ ¤¦©¨ • This is transaction schedule; commit ….. applies to these operations ¢¡£ ¤§¦©¨ ….. transaction to the state • No internal structure they had when the if condition then abort • Accesses a single DBMS transaction first accessed commit commit • Adequate for simple applications them. 3 4 Some Limitations of Flat Transactions • Only total rollback (abort) is possible – Partial rollback not possible Providing Structure Within a • All work lost in case of crash Single Transaction • Limited to accessing a single DBMS • Entire transaction takes place at a single point in time 5 6 1 Savepoints begin transaction S1; Savepoints Call to DBMS sp1 := create_savepoint(); S2; sp2 := create_savepoint(); • Problem: Transaction detects condition that S3; requires rollback of recent database changes if (condition) {rollback (sp1); S5}; S4; that it has made commit • Solution 1: Transaction reverses changes • Rollback to spi causes database updates subsequent to creation itself of spi to be undone – S2 and S3 updated the database (else there is no point • Solution 2: Transaction uses the rollback rolling back over them) facility within DBMS to undo the changes • Program counter and local variables are not rolled back • Savepoint creation does not make prior database changes 7 durable (abort rolls all changes back) 8 Distributed Systems: Integration Example of Savepoints of Legacy Applications • Problem: Many enterprises support multiple • Suppose we are making airplane legacy systems doing separate tasks reservations for a long trip – Increasing automation requires that these systems be integrated – London-NY NY-Chicago Chicago-Des Moines • We might put savepoints after the code that made withdraw part the London-NY and NY-Chicago reservations return part Inventory DBMS 1 Site B • If we cannot get a reservation from Chicago to stock level Application Des Moines, we would rollback to the savepoint order part after the London-NY reservation and then perhaps Billing Site C payment DBMS 2 try to get a reservation through St Louis Application 9 10 Distributed Transactions Distributed Transactions • Incorporate transactions at multiple servers into a single (distributed) transaction • Goal: distributed transaction should be ACID – Not all distributed applications are legacy systems; some are built from scratch as distributed systems – Each subtransaction is locally ACID (e.g., local constraints maintained, locally serializable) tx_begin; Inventory DBMS 1 Site B – In addition the transaction should be globally ACID order_part; Application • A: Either all subtransactions commit or all abort withdraw_part; • C: Global integrity constraints are maintained payment; Billing DBMS 2 Site C tx_commit; Application • I: Concurrently executing distributed transactions are globally serializable Site A • D: Each subtransaction is durable 11 12 2 Banking Example Banking Example (con’t) • Global atomicity - funds transfer • Global consistency - – Either both subtransactions commit or neither does – Sum of all account balances at bank branches = total assets recorded at main office tx_begin; withdraw(acct1); deposit(acct2); tx_commit; 13 14 Exported Interfaces Banking Example (con’t) Local system might export an interface for executing • Global isolation - local serializability at each site individual SQL statements. does not guarantee global serializability – post_interest subtransaction is serialized after audit subtransaction subtransaction in DBMS at branch 1 and before audit tx_begin; DBMS 1 site B ¤§¦©¨ ¦ ¥¤¢¡¥ in DBMS at branch 2 (local isolation), but ¡£ ¢£ ¤ ¦ ¦¥§¡¥ – there is no global order ¡£ ¤§¦©¨ ¡£ ¤§¦©¨ ¦ ¤¢¡ post_interest audit DBMS 2 site C time tx_commit; ↓ sum balances at branch 1; site A subtransaction post interest at branch 1; post interest at branch 2; Alternatively, the local system might export an interface sum balances at branch 2; for executing subtransactions. 15 16 Multidatabase Transaction Hierarchy • A distributed transaction invokes subtransactions. • Set of databases accessed by a distributed • General model: one distributed transaction might transaction is referred to as a multidatabase (or invoke another as a subtransaction, yielding a federated database) hierarchical structure – Each database retains its autonomy and might support local (non-distributed) transactions Distributed transactions • Multidatabase might have global integrity constraints – e.g., Sum of balances of individual bank accounts at all branch offices = total assets stored at main office 17 18 3 Models of Distributed Transactions Distributed Transactions • Can siblings execute concurrently? • Transaction designer has little control over • Can parent execute concurrently the structure. Decomposition fixed by with children? distribution of data and/or exported • Who initiates commit? interfaces (legacy environment) Hierarchical Model: No concurrency among subtransactions, root initiates commit • Essentially a bottom-up design Peer Model: Concurrency among siblings and between parent and children, any subtransaction can initiate commit 19 20 Characteristics of Nested Transactions Nested Transactions • (1) Parent can create children to perform subtasks; children might • Problem: Lack of mechanisms that allow: execute sequentially or concurrently; – a top-down, functional decomposition of a parent waits until all children transaction into subtransactions complete (no communication – individual subtransactions to abort without between parent and children). aborting the entire transaction • (2) Each subtransaction (together with its descendants) is • Although a nested transaction looks similar isolated with respect to each sibling (and its descendants). to a distributed transaction, it is not Hence, siblings are serializable, but order is not determined conceived of as a tool for accessing a and nested transaction is non-deterministic. multidatabase • (3) Concurrent nested transactions are serializable. 21 22 Characteristics of Nested Transactions Nested Transaction - Example Booking a flight from • (4) A subtransaction is atomic. It can London to Des Moines abort or commit independently of other L -- DM C subtransactions. Commit is conditional concurrent C = commit on commit of parent (since child task is a A = abort subtask of parent task). Abort causes C L -- NY C NY -- DM abort of all subtransaction’s children. sequential • (5) Nested transaction commits when root commits. At NY -- Chic -- DM A concurrent C NY -- StL -- DM that point updates of committed subtransactions are made stop in Chicago concurrent stop in St. Louis durable. C/A A C C 23 NY -- Chic Chic -- DM NY -- StL StL -- DM24 4 Nested Transactions parent of all Characteristics of Nested nested transactions Transactions • (6) Individual subtransactions are not necessarily concurrent consistent, but nested transaction as a whole is consistent isolation isolation isolation 25 26 Structuring to Increase Example - Switch Sections Transaction Performance transaction moves student from section • Problem: In the models previously discussed, a s1 to section s2, transaction generally locks items it accesses and holds Move(s1, s2) uses TestInc, Dec locks until commit time to guarantee serializabiltiy Section abstr. acquire lock on x release lock on x L2 TestInc(s2) Dec(s1) ↓ ↓ T1: r(x:12) .. compute .. w(x:13) commit Tuple abstr. enrollments T2: request read(x) r(x:13) ..compute.. w(x:14) .. L1 Sel(t2) Upd(t2) s t o r e d i n t u p l e s Upd(t1) t1 and t2 ↑ ↑ Page abstr. (wait) acquire lock on x L0 Rd(p2) Rd(p2) Wr(p2) Rd(p1) Wr(p1) – This eliminates bad interleavings, but limits concurrency and tuples stored hence performance in pages 27 time p1 and p2 28 Chained Transactions • Problem 1 (trivial): Invoking begin_transaction at the start of each Structuring into Multiple transaction involves communication Transactions overhead • With chaining, a new transaction is started automatically for an application program when the program commits or aborts the previous one – This is the approach taken in SQL 29 30 5 Chained Transactions Chained Transactions transaction • Problem 2: If the system crashes during the starts execution of a long-running transaction, begin transaction begin transaction implicitly considerable work can be lost S1 S1 S1 commit commit commit S2 S2 begin transaction • Chaining allows a transaction S1; S3 begin transaction S2 S1 commit; commit to be decomposed into sub- S3 S3 S2 => S2; commit commit transactions with intermediate S3 commit; commit points commit S3; S2 not included in a Equivalent since Chaining • Database updates are made commit; transaction since it S2 does not access equivalent has no db operations the database durable at intermediate points => less work is lost in a crash 31 32 Example Chaining Considerations - S1; -- update recs 1 - 1000 Atomicity commit; S2; -- update recs 1001 - 2000 commit; • Transaction as a whole is not atomic. If S3; --