3/6/99 1 Advanced Transaction Models CSE593 - Transaction Processing Philip A. Bernstein

3/6/99 2 Outline 1. Introduction 2. Multi-transaction Requests 3. Nested Transactions 4. A Quick Research Survey

3/6/ Introduction For over 15 years, people have investigated how to extend the transaction abstraction to broaden its applicability Most of this work is still at the research stage or has undergone limited commercial deployment Still, it’s worth understanding where the technology is headed

3/6/ Multi-Transaction Requests Some requests cannot execute as one transaction because –it executes too long (causing lock contention) or –Resources don’t support a compatible 2-phase commit protocol. Transaction may run too long because –It requires display I/O with user –People or machines are unavailable (hotel reservation system, manager who approves the request) –It requires long-running real-world actions (get 2 estimates before settling an insurance claim) –Subsystems’ transactions must be ACID (placing an order, scheduling a shipment, reporting commission)

3/6/99 5 Workflow A multi-transaction request is called a workflow Specialized workflow products are being offered. –IBM Flowmark, Action, JetForm, Wang/Kodak,... They have special features, such as –flowgraph language for describing processes consisting of steps, with preconditions for moving between steps –representation of organizational structure and roles (manual step can be performed by a person in a role, with complex role resolution procedure) –tracing of steps, locating in-flight workflows –ad hoc workflow, integrated with (case mgmt)

3/6/99 6 Managing Workflow with Queues Each workflow step is a request Send the request to the queue of the server that can process the request Server outputs request(s) for the next step(s) of the workflow Submit expense claim Validate claim Get Manager Approval Authorize Payment Request Automatic Deposit notification

3/6/99 7 Workflows Can Violate Atomicity and Isolation Since a workflow runs as many transactions, –it may not be serializable relative to other workflows –it may not be all-or-nothing Consider a money transfer run as 2 txns, T 1 & T 2 –Conflicting money transfers could run between T 1 & T 2 –A failure after T 1 might prevent T 2 from running –These problems require application-specific logic –E.g. T 2 must send ack to T 1 ’s node. If T 1 ’s node times out waiting for the ack, it takes action, possibly compensating for T 1

3/6/99 8 Automated Compensation In a workflow specification, for each step, identify a compensation. Specification is called a saga. If a workflow stops making progress, run compensations for all committed steps, in reverse order (like txn abort). Need to ensure that each compensation’s input is available (e.g. log it) and that it definitely can run (enforce constraints until workflow completes). Concept is still at the research stage.

3/6/99 9 Pseudo-conversations A conversational transaction interacts with its user during its execution. Since this is long-running, it should run as multiple requests Since there are exactly two participants, just pass the request back and forth –request carries all workflow context –request is recoverable, e.g. send/receive is logged or request is stored in shared disk area This is a simpler mechanism than queues

3/6/99 10 Fault Tolerance By Logging Device I/O Consider a transaction all of whose operations are undoable. Log all of the transaction’s interaction with the outside world. If the transaction fails, replay it. During the replay, –get input from the log –validate that output is identical to what was logged. –If the output diverges from the log, then start asking for live input (and the ignore rest of the log). A variation of this is used by Digital’s RTR

3/6/ Nested Transactions All important concepts in computer science are recursive – why not transactions? –Transactions can have subtransactions, which can have subtransactions, etc. Nested transactions generalize savepoints –Savepoints allow sequential transactions to be backed out partially … the work between two savepoints is a subtransaction –Nested transactions allow a tree of concurrent transactions where each subtransaction can be aborted

3/6/99 12 Nested Transaction Rules Each transaction or subtransaction is bracketed by Start and Commit or Abort. If a program is not executing a transaction, then Start creates a new top-level transaction If a program is executing inside a transaction, then Start creates a subtransaction. Example - BookTrip is a top-level transaction –It calls three subroutines, BookFlight, BookCar, BookHotel, each of which is bracketed by Start and Commit/Abort and thus executes as a subtransaction.

3/6/99 13 Nested Transaction Rules (cont’d) Commit and Abort by a top-level transaction have the usual semantics If a subtransaction aborts, then all of its operations and subtransactions are undone. Until it commits, a subtransaction’s updated data items are only visible to its subtransactions After a subtransaction S commits, S’s updates are visible to other subtransactions of S’s parent. –E.g. After BookFlight commits, its updates are visible to BookCar and BookHotel, but not before it commits.

3/6/99 14 Nested Transaction Semantics Top-level transactions are like flat transactions. –They’re ACID and bracketed by Start, Commit, Abort. Subtransaction abort is a new feature. Subtransactions of the same parent are isolated from one another (= SR w.r.t. one another)

3/6/99 15 Applications Not as many as you’d think … Allows you to construct ACID operations out of ACI components A good abstraction for OO applications –Objects call sub-objects –Interesting language integration in Argus [Liskov 88] A good abstraction for parallel DB systems –Can decompose an operation into ACI sub-operations

3/6/99 16 Implementation Each resource manager accessed by a nested transaction needs special capabilities –Subtransaction start - so it knows which operations are relevant to a given subtransaction –Each operation on the RM must have the subtransaction’s transaction identifier –Subtransaction abort - to undo updates of a given subtransaction –Subtransaction commit - to make its updated data visible to other subtransactions (subtransaction’s parent inherits its locks)

3/6/99 17 Implementation (cont’d) Implementation of subtransaction abort affects the logging algorithm and 2-phase commit implementation

3/6/99 18 Multi-Level Transactions Nested transactions with a twist: –Each subtransaction “type” has an associated undo action To abort a transaction, you –undo the transaction’s atomic operations –undo its committed subtransactions –abort its active subtransactions Useful for multi-step DB system operations, e.g. –B-tree splits –operations that update a record and an index

3/6/99 19 Commercial Support Nested transactions were a hot research topic in the early-mid 1980’s, but has not caught on (yet) in products. Transarc’s Encina TP monitor supports nested transactions, with some Transarc RMs. No commercial DB systems support nested transactions. No standard 2-phase commit protocols support it.

3/6/ A Quick Research Survey There is a big research literature in extended transaction models. It comes roughly in 4 flavors –active databases –workflow models –design transaction models –theoretical models

3/6/99 21 Active Databases SQL systems support triggers –consists of a predicate (WHERE clause) and action –attach it to certain operations on a table (INSERT, DELETE, UPDATE) –when the operation runs, check which triggers’ predicates are true and run them Generalization is Event-Condition-Action rules This is a foundational mechanism for multi-txn requests, since it encapsulates declarative behavior about how txns can affect one another.

3/6/99 22 Workflow Models There are proposals for combinations of dataflow programs and atomicity models (compensation, preconditions for next steps, recoverability) E.g. ConTract model [Wachter, Reuter] –workflow state information after each (transaction) step is recoverable –after a failure, active workflows can be reinstantiated and continue running –stores database invariants to ensure workflow is forward recoverable

3/6/99 23 Design Transactions Concurrent design activities between designers must be coordinated. Transaction models for this application usually break the ACID rules. I find them unappealing. My preferred model uses versioned configurations –Configuration contains a set of related design objects that must be mutually consistent. –Designer checks out a set of objects to a workspace configuration (maybe incrementally). –When finished, the set of objects is checked back into a new version of the shared configuration (this is atomic w.r.t. other check-ins)

3/6/99 24 Design Transactions (cont’d) –If the configuration version changed since the designer’s original checkout, then the checkin must merge conflicting results. (Essentially, optimistic locking fails. Rather than abort, you merge the inconsistent updates) –Workspace configuration represents the long transaction C1 C2 C3 W AL W Sue checkout checkin merge

3/6/99 25 Theoretical Models Define dependencies between transactions (that comprise a larger atomic unit) –commit dependency - if T 1 and T 2 both commit, then T 1 commits first –strong commit dependency - if T 1 commits, then T 2 commits –abort dependency, termination dependency, …. Two good models for this –ACTA [Chrysanthis, Ramamritham] –temporal logic and finite automata [Klein] Can write axiomatic definitions of txn models using dependencies, maybe leading to implementations.