Back to index
ACTA: A Framework for Specifying and Reasoning about Transaction Structure
Panayiotis K. Chrysanthis and Krithi Ramamritham
Summary by: Steve Gribble and Armando Fox
ACTA is a formalizable framework developed for characterizing the entire
spectrum of transaction models and interactions - a unification of all
Fairly nice characterization of access semantics of transactions.
- is this truly general? Proof by 5 examples is convincing, but
- is this pragmatic/useful? Given an ACTA model, now what do I do
- is this correct? How does one demonstrate convincly without
hand-waving that an ACTA model does in fact capture the semantics
of the transaction model?
- transaction model is lacking in functionality and efficiency for
complex info systems like CAD/CAM. Functionality - need reactive
(endless), open-ended (long lived), and collaborative
(interactive) activies supported.
- ACTA - semantics of interactions between transactions are
expressed in terms of effects on each other (in terms of abort or
commit) and on accessed objects (in terms of state or concurrency
status). Both structure and behaviour of transactions are
specifiable in ACTA.
- transaction specific concurrency - allows operations invoked by
two transactions to be interleaved if application semantics can
tolerate dependencies to be ignored. Transaction specific
recovery - similar, but for recovery and failure handling.
- Effects of transactions on other transactions
- commit-dependency: if transaction A develops commit
dependency on B, then A cannot commit until B either
commits or aborts.
- abort-dependency: of A develops abort dependency on B,
and if B aborts, then A should also abort.
- these dependencies impose commit order that prevent
inconsistencies. Circular dependencies possible and
should be avoided.
- exclusive abort dependency - transaction not allowed to
develop abort dependency on more than one other
- can define transitive commit and transitive abort
dependency in the obvious way
- dependencies are stored in a compatibility table
associated with each object
- Effects of transactions on objects
- object characterized by state (contents) and status
- view set - all objects potentially accessible to a
- access set - objects already accessed by a transaction;
accessibility based on concurrency control
compatibility info of object. Abort moves object back
to view set. Commit moves changes back to view set.
- transaction can delegate some of its access set objects
to the access set of another transaction.
- Modeling different transaction schemes
- Nested Transactions
- transactions are composed of subtransactions
- subtransaction can access any object of
- If C is child transaction of parent P, then:
- For all C, Child exclusive abort P and
P commit dependency C.
- View set specification: for all C, ViewSet(C)
is (set of all AccessSets of A such that C
transitive abort A) union DB. (This is
an ordered union.)
- Delegation occurs when C commits: for all C,
DelegateSet(C to P) is equal to
AccessSet of C. I.e. at commit, child
transaction's objects are delegated to parent.
- Split transactions
- transaction A splits into two transactions
B,C. B,C may be independent (in which case
they commit/abort independently) or serial
(in which case B must commit for C to
- can also have 3rd model in which 2
transactions join into one.
- (Logic omitted - see paper)
- new framework that is composition of nested
- ACTA handles it, but not clear of the
- Recoverable communicating actions
- deals with non-hierarchical computations.
- an action (sender) is allowed to communicate
with another action (receiver) by exchanging
objects, resulting in an abort-dependency of
receiver on sender.
- because of dependencies, RcAs form
recoverable computation, self-contained task
which has semantics of atomic update.
- again, ACTA handles it.
- Cooperative transactions
- transactions composed into subtransactions,
each with own semantics and types. Three
types of subtransactions:
- project transactions are decomposed
into cooperative transactions
- cooperative transactions are
composed of a set of subcontractor
- subcontractor transactions may
either have cooperative transaction
structure or have structure of
atomic transaction (called a short
- similar to nested transactions, but don't
support object inheritance in same manner.
Object flow is supported only between
adjacent levels through semi-public or
- Again, ACTA handles it.
Back to index