Implementing Causal Logging Using Interception

Consider implementing causal logging on top of CORBA. The following properties of an implementation state what we believe constitutes a well-engineered solution.

• Transparency. The piggybacking and stripping of piggybacked information should be implemented without explicit involvement of the objects using causal logging. To do otherwise would make it hard to ensure that the causal logging mechanism is correct.

• Scheduling. Causal logging implies that information is made available to an object at certain points in its execution. To do otherwise might violate the causal consistency condition. Hence, the causal logging mechanism notifies of the delivery of causal information ordered with respect to the invocation of methods and creation of new objects.

• Context Sensitivity. The information that an object a piggybacks to an object b may depend both on the state and class of a and on the class of b. Without knowledge about a, it is hard to piggyback any information because there is no way to obtain it, and without information about b an object would have to piggyback all possibly useful information on every method invocation. The latter would both be inefficient and would pose a possible security problem.

CORBA interception is ideally suited as a piggybacking mechanism that provides the properties of transparency and scheduling. Interceptors are orthogonal to the regular path of computation, and therefore provide transparency. Furthermore, since interception can be placed at many points in the method invocation sequencing, it can be used to provide scheduling as well.

A simple implementation of causal logging would be as follows. Consider an interception mechanism in which every object has an interceptor that is specific to that object. The interceptor knows the identity of the object with which it is associated, and the interceptor is invoked upon both ends of a method invocation--that is, by the invoked object and by the invoking object.

When a method is invoked, the interceptor on the invoking object uses some mechanism to determine what type of information is to be piggybacked. This mechanism can base its determination on the class of the invoked object. The actual information can be determined from the current state and the class of the invoking object. Hence, context sensitivity is implemented. The interceptor adds this data to the outgoing method invocation.

When the invoked object receives the invocation, its interceptor removes the data that was added by the invoking object's interceptor. The invoked object's interceptor then implements scheduling by ordering the method invocations that deliver the causally logged information with respect to the incoming method invocation.

This scheme implements encapsulation of the method invocations within the causal logging mechanism. That is, the underlying method invocations are not altered, but rather are used as a conduit of causally logged information and are scheduled to maintain causal consistency. The CORBA interception facility is intended for exactly this kind of encapsulation. Our simple model of CORBA interception requires the following capabilities:

1.

Interceptors should be invoked on all outgoing and incoming invocations.

2.

Interceptors should be able to add information when a method invocation is initiated at the invoking side and remove information when the method invocation is initiated at the invoked side.

3.

An interceptor on the invoking side should know the state and class of the object with which it is associated and the class of the object being invoked.

4.

An interceptor on the invoked side should have the ability to make method calls on the object with which it is associated before it allows the initiating method to be invoked.

As discussed in Section 5, we had a few difficulties in creating such an architecture in OrbixWeb.