Advanced Transaction Models

1. Advanced Transaction Models CSE593 - Transaction Processing Philip A. Bernstein

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

3. 1. 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

4. 2. 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)

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 e-mail (case mgmt)

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 Request Automatic Deposit Email notification Authorize Payment

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, T1 & T2 • Conflicting money transfers could run between T1 & T2 • A failure after T1 might prevent T2 from running • These problems require application-specific logic • E.g. T2 must send ack to T1’s node. If T1’s node times out waiting for the ack, it takes action, possibly compensating for T1

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.

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

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

11. 3. 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

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.

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.

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)

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

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)

17. Implementation (cont’d) • Implementation of subtransaction abort affects the logging algorithm and 2-phase commit implementation

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

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.

20. 4. 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

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.

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

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)

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 checkout C1 checkout WAL WSue checkin C2 checkin merge C3

25. Theoretical Models • Define dependencies between transactions (that comprise a larger atomic unit) • commit dependency - if T1 and T2 both commit, then T1 commits first • strong commit dependency - if T1 commits, then T2 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.