CSE593 - Transaction Processing
Philip A. Bernstein
2. Multi-transaction Requests
3. Nested Transactions
4. A Quick Research Survey
• For over 15 years, people have investigated how to
extend the transaction abstraction to broaden its
• Most of this work is still at the research stage
or has undergone limited commercial deployment
• Still, it’s worth understanding where the technology
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
• 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) 4
• 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)
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
Submit expense Validate Get Manager
claim claim Approval
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
• 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.
• A conversational transaction interacts with its user
during its execution.
• Since this is long-running, it should run as multiple
• 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
Fault Tolerance By Logging Device I/O
• Consider a transaction all of whose operations are
• Log all of the transaction’s interaction with the
• 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. 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
– Nested transactions allow a tree of concurrent
transactions where each subtransaction can be aborted
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.
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.
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)
• Not as many as you’d think …
• Allows you to construct ACID operations out of
• 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
• 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 commit - to make its updated data visible
to other subtransactions (subtransaction’s parent inherits
• Implementation of subtransaction abort affects
the logging algorithm and 2-phase commit
• 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
• Nested transactions were a hot research topic in the
early-mid 1980’s, but has not caught on (yet) in
• Transarc’s Encina TP monitor supports nested
transactions, with some Transarc RMs.
• No commercial DB systems support nested
• No standard 2-phase commit protocols support it.
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
• SQL systems support triggers
– consists of a predicate (WHERE clause) and action
– attach it to certain operations on a table (INSERT,
– 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.
• 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
– after a failure, active workflows can be reinstantiated
and continue running
– stores database invariants to ensure workflow is forward
• 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) 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
• 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
– 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