518 DISTRIBUTED OBJECT-BASED SYSTEMS CHAP. 9
participating in a two-phase commit protocol. In particular, the server for such an object can support the abort of a transaction by rolling back all the changes that were made as the result of invoking one of its recoverable objects. However, it is also possible to invoke objects as part of a transaction that cannot be rolled back to a state before the transaction started. In particular, these transactional objects are executed by servers that do not participate in a transaction’ s two-phase commit protocol. Transactional objects are typically read-only objects.
Thus it is seen that CORBA transactions are similar to the distributed transactions and their protocols as we discussed in Chaps. 5 and 7.
Likewise, the locking services provided by the concurrency control service are very much what one would expect. In practice, the service is implemented using a central lock manager; it does not use distributed locking techniques. The service distinguishes read from write locks, and is also capable of supporting locks at different granularities as is often needed in databases. For example, it makes sense to distinguish locking an entire table from locking only a single record. See( Gray and Reuter, 1993; or Garcia-Molina et al. 2000) for further information on granular locking.
9.1.6 Caching and Replication
CORBA offers no support for generic caching and replication. Only the replication of objects for fault tolerance as we describe in the next section is included in version 3 of CORBA. The lack of support for generic replication implies that application developers will have to resort to an ad-hoc approach when replication is needed. In most cases, such approaches are based on using interceptors.
Let us consider one example of how replication for performance can be incorporated into CORBA. This objective is met by CASCADE. In the CASCADE system, the goal is to provide a generic, scalable mechanism that allows any kind of CORBA object to be cached( Chockler et al., 2000). CASCADE offers a caching service that is implemented as a potentially large collection of object servers each referred to as a Domain Caching Server( DCS). Each DCS is an object server running on a CORBA ORB. The collection of DCSs may be spread across a wide-area network such as the Internet.
Cached copies of the same object are organized into a hierarchy. It is assumed that a single client, such as the owner of an object, can register that object with a local DCS. That DCS becomes the root of the hierarchy. Other clients can request their local DCS to cache a copy of the object, for which that DCS will first join the current hierarchy of DCSs that already cache the object.
CASCADE supports the client-centric consistency models we discussed in Chap. 6. In addition, it supports total ordering by which all updates are guaranteed to be performed in the same order everywhere. Each object may have its own associated consistency model; there is no systemwide policy for maintaining the consistency of cached objects. As we argued in Chap. 6, when replicating for