Consistency Framework Check out the new USENIX Web site.



next up previous
Next: Implementation Framework Up: Implementation Previous: Implementation

Consistency Framework

  At the root of the consistency framework is the Distributed Object class. Because an object reference is opaque, it is not a convenient value for storing references to objects in persistent storage or communicating references by means other than invocation. The Distributed Object class interface provides methods such as stringify and objectify to solve the above problem. Actually, the object request broker (ORB) interface in the CORBA specification provides more ``heavyweight'' methods such as the object_to_string and string_to_object to solve a similar problem; these methods in the ORB interface additionally help to convert an ORB dependent distributed object reference to an ORB independent object reference and vice-versa. We provide these methods in the Distributed Object class because the implementation of Fresco, that we use, does not support these methods of the ORB interface.

One of the subclasses of the Distributed Object class is the Proxy class. This reflects the style of access that is specified by CORBA and is generally available in existing CORBA compliant systems. Basically, when a client tries to access an object server, it receives a handle to a proxy object [33]. Any invocation on the proxy object is translated into an invocation at the remote object server. Thus, objects that are not intended to be cached such as wrappers around hardware devices are designed to be instances of classes that are descendants of the Proxy class.

Another subclass of the Distributed Object class is the Cached class. As we shall see later, one of the enabling mechanisms we use to implement caching is to stringify object state, pass it over the network and reconstitute the object at the other end. The writeToString and the readFromString methods accomplish this. In writeToString, the relevant object state is linearized and written out as a string. This string can now be sent out on the wire and the readFromString method on the other end can read from the string and update the object's state. Note that this is not the same as the methods we talked above in the context of the Distributed Object class. In that class, only the means to access the remote object can be stringified; in contrast, the methods described here stringify the object state and make it possible to transfer object state between processes. A similar interface is part of CORBA's Externalization service proposal. Our intention is for the class implementors (who wish that instances be cached and thus inherit from one of the descendants of the Cached class) to have the option to override the readFromString and the writeToString methods defined by default in the Cached class. The advantage of such a provision is that the class implementor knows a great deal about the class and therefore can provide optimizations. For example, if instances of a cacheable object have a large state and it is known that the relevant state information that needs to be passed amongst object copies is only a small part of the entire state (e.g., only the modifiable parts of the state), then it is more efficient to stringify only that part of the state instead of the entire object state. Also, as we pointed out in section 3, objects have references to other objects. These two methods allow the class implementor to decide which of the referenced objects need to be faulted in and which of them will just be sent as object references. Of course, if the class implementor does not override these methods, the default mechanism is for a preprocessor to generate these methods automatically.

The subclasses of the Cached class implement the specifics related to providing different consistency guarantees. The caching framework shown in figure 2, shows only two subclasses of the Cached class that provide strong and causal consistency guarantees. Ultimately, we intend to provide a bigger suite of consistency classes somewhat similar in flavor to the various session guarantees provided in Bayou[35]. The discussion on the relevance of the different consistency guarantees and their details can be found in [20].



next up previous
Next: Implementation Framework Up: Implementation Previous: Implementation



Rammohan Kordale
Tue May 7 09:16:10 EDT 1996