COPE

We have implemented a new CORBA service called COPE that is based on causal logging. We give a brief overview of COPE to ground the discussion in Section 3 on what we require of a CORBA causal logging implementation.

One of the two abstractions that COPE implements is the class of assumptions. An assumption is a CORBA object that is eventually either asserted or refuted. An assumption keeps track of the objects that wish to be notified when it is resolved. Assumptions can also be subclassed to associate semantics with them, such as assumptions that depend on other assumptions. An example of such an assumption is a proposition which is expressed as a boolean formula over a symbol table. Each entry in the symbol table is itself an assumption. A proposition assumption becomes asserted or refuted when the value of its formula evaluates to true or false as determined by the assumptions that have been asserted and refuted in the symbol table.

The other abstraction that COPE implements is the class of optimists. An optimist is a CORBA object that takes on assumptions. Optimists can execute optimistically based on the assumptions that it has taken on. More specifically, an optimist can either checkpoint its state when it takes on an assumption or it can block, awaiting the eventual assertation or refutation of the assumption. If, in either case, the assumption is asserted then the optimist is notified so that it can either discard the checkpoint or continue execution. If, on the other hand, the assumption is refuted, then the optimist is notified so that it can either roll it state back to the associated checkpoint or continue execution knowing that the assumption was refuted.

Assumptions are causally consistent with respect to CORBA communications. For example, consider optimist a invoking method b.m on optimist b. If a has taken on an assumption x which is still unresolved by the time a invokes b.m, then b must take on x by the time it begins execution of b.m. Similarly, if b.m constructs an optimist c, then c must also take on x by the time c completes initialization.

Put into terms of shared memory, each optimist has a list of replicas of unresolved assumption. These replicas are causally consistent, where ``causally depends'' is defined in terms both of optimists invoking methods on other optimists and of optimists creating new optimists. This list is maintained as follows:

1.

When an optimist a makes a method invocation on an optimist b, it piggybacks on the method invocation a list of unresolved assumptions that a has taken on.

2.

When an optimist b has a method invoked by an object a, b checks to see if a has a class that derives from Optimist. If so, then b strips off any assumptions piggybacked on the method invocation and decides whether to add them to its own list of unresolved assumptions or to block the invocation.

3.

When an optimist a creates an optimist b, it makes a method call to an optimist factory. As when invoking a method on an optimist, a piggybacks on the method invocation a list of assumptions that a has taken on. The factory f checks to see if a has a class that derives from Optimist. If so, it then passes a's unresolved assumptions to b. Optimist b can choose either to accept a's assumptions, in which case the creation is successful, or to deny them, in which case b is not created.

These three rules for maintaining the list of assumptions together implement causal logging of assumptions. Other features of COPE, such as assertion resolution and object notification, are not germane to the discussion. Interested readers can find further details on COPE in [8].