ACTA: A Framework for Specifying and Reasoning about Transaction Structure and Behaviour

Summary by: Steve Gribble and Armando Fox

One-line summary: ACTA is a formalizable framework developed for characterizing the entire spectrum of transaction models and interactions - a unification of all possible models.

Relevance

Flaws

• is this truly general? Proof by 5 examples is convincing, but not absolute.
• is this pragmatic/useful? Given an ACTA model, now what do I do with it?
• 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?

Overview/Main Points

• 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 transaction.
  • 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 (synchronization information).
  • view set - all objects potentially accessible to a transaction
  • 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 ancestor transaction
    • 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 commit).
    • can also have 3rd model in which 2 transactions join into one.
    • (Logic omitted - see paper)
  • Nested-Split
    • new framework that is composition of nested and split.
    • ACTA handles it, but not clear of the framework's usefulness
  • 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 transactions
      • subcontractor transactions may either have cooperative transaction structure or have structure of atomic transaction (called a short transaction).
    • 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 subcontractor databases.
    • Again, ACTA handles it.