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, its 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 dont 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
Authorize Payment
Email notification
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 T1s node. If T1s 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 compensations 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 transactions 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 Digitals 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 (contd)

• 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 subtransactions updated data
  items are only visible to its subtransactions
• After a subtransaction S commits, Ss updates are
  visible to other subtransactions of Ss 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.
• Theyre 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 youd 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
  subtransactions transaction identifier
• Subtransaction abort - to undo updates of a given
  subtransaction
• Subtransaction commit - to make its updated data
  visible to other subtransactions
  (subtransactions parent inherits its locks)

17
Implementation (contd)

• 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 transactions 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 1980s, but has not caught on (yet)
  in products.
• Transarcs 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 (contd)

• If the configuration version changed since the
  designers 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.