We saw in the previous section that caching considerably reduces latency in accessing shared distributed objects when applications exhibit a reasonable amount of locality of reference. One of the goals of our system is scalability. There are many aspects of scalability. We believe that by allowing applications to use weaker consistency models whenever applicable, the overall scalability of the system is improved. Towards this end, we provide flexible notions of state consistency in our system. Another aspect of scalability that can be of concern is the size of the vector timestamps that we associate with each object copy. Various efficient implementations that reduce the space overhead considerably are outlined in [36][32]. Below, we comment on our experiences with the present CORBA specification and UNIX.
Passing object reference by value: CORBA compliant systems have the advantage over many commercial RPC systems in that they allow object references to be manipulated as first-class values in a straight-forward manner. In particular, an object reference can be sent as an argument of an invocation on an object server. Thus, CORBA compliant systems provide for network-wide references, and support distributed object reference semantics. However, this does not always provide the required semantics. For example, an application might want to pass ``an object reference'' by value just like pointer structures are passed by value. For example in Flex, many method invocations in the caching framework take a vector timestamp as one of the arguments. We have defined a VectorTimeStamp IDL interface and we will call the instances of this class as vector timestamp objects. Now, suppose that we want to pass the vector timestamp arguments as references to objects of type VectorTimeStamp in invocations on the object server. Firstly, we need to activate an object server to service the vector timestamp object sent as an argument. Moreover, every invocation on such an object reference (argument) would be an inter-address space invocation which we clearly want to avoid.
Ideally, we would like to have the choice to pass an object reference argument by ``value'' as in [17][25][16][6]. The object structure should be linearized, sent over the wire, reconstructed at the other end and finally, we should be able to make an object invocation locally at that end.
Transport interface: CORBA specifications include synchronous, asynchronous, and one-way remote object invocations. From our experience, we found that multicast is an important mechanism that is useful in consistency maintenance in distributed object systems. For example in Flex, each time an object copy is validated, the node cacher at the owner node can potentially contact node cachers on all nodes on which clients contain copies of the object. This is a perfect candidate for exploiting multicast communication. Though a system level multicast may be available, it cannot be used because the CORBA ORB API does not support it. In [24], the authors argue the need for a multicast interface in the context of object groups.
UNIX and object-oriented technology: We mentioned in section 3 that we use virtual memory (VM) mechanisms for object faulting and access detection. This does lead to some compromise on the object oriented aspect of system development. For example, consider the following scenario. A client faults on a causally consistent object and experiences a segmentation fault. The object fault handler code is defined in the Causal class of the consistency framework. The handler returns with the new object state. At this point, the local object copy needs to be created or updated using the received object state. The readFromString method in the Cached class (or overriding method in the object's class) defines the code that needs to be used to update the object copy's state. However, the handle to the object that is obtained as a result of a segmentation fault is a pointer to an object of type char. Since the reference is not appropriately typed, the readFromString method cannot be invoked. Our solution, which is outlined below, departs from object technology. Each process maintains a function table that contains the address of the readFromString method of every type of object for which the client has a reference. When a client creates an object reference, the constructor of the corresponding class invokes the constructor of the Causal class with one of the arguments being the address of the readFromString method. This address is stored in the function table. Later, when object state is received as a result of an object fault, the stored address of the corresponding readFromString method is used to update the local object copy. This could be used as a reason to adopt software based solutions instead of VM based schemes for object faulting and access detection.
Caching as an object service: The Object Management Architecture guide [29] includes a reference model which identifies and characterizes the components, interfaces, and protocols that compose the OMA. The reference model consists of four major parts - the object request broker (ORB), object services, common facilities, and application objects. The ORB enables objects to transparently make and receive requests and submissions in a distributed environment. Object Services is a collection of services (interfaces and objects) that support basic functions for using and implementing objects. Common Facilities is a collection of services that provide general purpose capabilities useful in many applications while application objects are objects specific to particular end-user applications.
As we pointed out earlier, it is neither desirable nor possible to cache all objects. Furthermore, different consistency guarantees may be required of cached copies. Thus, caching should be provided as a Common Object Service and not as part of the ORB. The differences in object caching which manifested in the design of the consistency framework can serve as the interface of the object service itself. We discussed an extension to the IDL while arguing the need to pass objects by value. We also pointed out a desirable enhancement to the interface that CORBA provides to its applications when we argued about the need for multicasting. We also broached upon the issue of providing library object adaptors which are linked with the client applications and which help find implementations of objects that get cached. Clearly more issues remain to be explored, particularly in the realm of identifying interactions with other object services. Our intention in this paper is only to provide a data point in a discussion of issues related to caching in CORBA.