Docstoc

Workflow

Document Sample
Workflow Powered By Docstoc
					         Advanced Transaction
               Models
           CSE593 - Transaction Processing
                Philip A. Bernstein



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




3/6/99                               2
                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



3/6/99                                                   3
       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
3/6/99
         order, scheduling a shipment, reporting commission)     4
                            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)
3/6/99                                                              5
         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    Validate      Get Manager
             claim          claim         Approval

                           Request
            Email                         Authorize
                          Automatic
          notification                    Payment
                           Deposit
3/6/99                                                     6
                   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
3/6/99                                                                7
         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                                                     8
                    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                                                              9
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/99                                                                  10
                  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
3/6/99                                                             11
                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                                                           12
         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                                                             13
            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                                                           14
                          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                                                             15
                        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                                                              16
          Implementation (cont’d)
• Implementation of subtransaction abort affects
  the logging algorithm and 2-phase commit
  implementation




3/6/99                                             17
             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                                                        18
            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/99                                                   19
                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




3/6/99                                                20
                       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                                                           21
                      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                                                            22
                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
3/6/99
         w.r.t. other check-ins)                                  23
              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
3/6/99                                                                24
               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.        25
3/6/99

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:16
posted:10/5/2011
language:English
pages:25