Models of Transactions Structuring Applications Flat Transaction Flat

Models of Transactions Structuring Applications Flat Transaction Flat

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; --

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    16 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us