Guardians and Actions: Linguistic Support for Robust, Distributed Programs

Liskov, Scheifler

paper proposed language support for building a distributed database system

proposed system is ARGUS, built on top of an object oriented language called CLU

provides atomiticity as a fundamental concept in the language

guardians are sort of like monitors

actions are transactions. nested subactions (nested transactions) are supported.

the paper re-names various traditional database concepts throughout.

it refers to Isolation (from ACID) as “indivisibility” and the all-or-nothing nature of a transaction as “recoverability.” not quite sure why the authors did this, as they seemed to be quite aware of database literature.

actions (transactions) commit or abort. isolation can be achieved by providing serializability (operations that take place in transactions are scheduled in a manner such that the results are equivalent to some serial schedule of transactions).

ARGUS provides read and write locks. objects must be locked appropriately before they can be used. multiple transactions can hold read locks on objects, or one transaction can hold a write lock on an object. when a write lock is obtained, a copy (version) of the object is made, and modifications are made to that object. if the transaction commits, the new version is saved to stable storage, and if the action aborts the older copy is retained.

system made the simplification of requiring that transactions hold on to locks they acquire to avoid the possiblity of cascading aborts.

system employs two-phase commit to ensure distributed consistency. hardware failures are handled as aborts of all transactions that were taking place at the node that failed.

subactions (nested transactions) can commit or abort without forcing their parent transaction to commit or abort. however, if a subaction commits and the parent aborts, the changes effected by the subaction will be aborted as well; this is, commits by subactions are conditional on the commit of the parent transaction.

They use RPCs with at-most once semantics. A given RPC call executes remotely at most once (per call) or not at all. This seems like a strategy that is very complementary to their goals and environment (transactions and high latency unreliable communication). (At-least once, and exactly-once are two other possible RPC call semantics, but are not used and are not discussed in the paper).

The effects of some actions (such as dispensing cash at an ATM) are un-do-able, and hence should be modeled with top-level actions in their system, since top-level actions are durable once they have committed. Subactions would not appropriately model undoable actions since subactions could be rolled back even if they commit due to the possibility of their top-level parent action aborting.

system did not do any deadlock detection or prevention, but instead required users to intervene to break deadlocks.

guardians are like monitors. handles are methods that provide synchronized access to a monitor.

Guardian structure

name = guardian [ parameter-decl ] is creator-name handles handler-names

{ [stable] variable declarations and initializers }

{ recover body end }

{ background body end }

{ method definitions }

end name

Note that guardians allow the programmer:

- to annotate variable as stable (stored on disk) or volatile (if an object is stable, all objects “reachable” by reference from the stable variable are stored to disk)

- to define a recovery procedure that gets invoked after a crash: recover should recreate object’s volatile state from its stored bits on disk

- run a background method that, well, executes in the background

“creators” are just constructors

handlers support regular termination (control reaches end of body), exceptions, or “failure” (equivalent to abort, and is a first-class way of ending a handler).

ARGUS provides support for concurrency through a “coenter” clause.