IT-SC book: Advanced CORBA® Programming with C++

reference counting easier for clients, but that solution only makes mistakes less likely instead of preventing them.

The additional calls over the network for the increment and decrement operations may generate more network traffic than we can tolerate, at least for short-lived objects.

12.7.10 Summary of Options

As the discussion shows, there are no easy solutions for garbage collection. The most promising approach is the Evictor pattern, which is easy to implement and effective in many situations. All the remaining options are difficult to implement, intrusive, proprietary, or error-prone and so are unlikely to be worth pursuing.

We could attempt to remedy some of the problems described here with additional effort or by combining various techniques. For example, in a distributed reference counting approach, we could use one of the ping techniques to adjust reference counts that are left too high by crashed clients. However, that brings us to the most serious drawback: it simply is not reasonable for application developers to invent grand garbage collection schemes for their applications. Not only is the effort required far too high, but also the different schemes would most likely be incompatible, and application developers would find themselves in a maze of incomprehensible garbage collection requirements.

For garbage collection to work in a practical manner, it must be provided by the platform. The OMG has taken initial steps to add garbage collection to CORBA [23]. However, it is likely that several more years will pass before we will see garbage collection as a platform feature. Until then, the Evictor pattern will have to do.

12.8 Garbage Collection of CORBA Objects

So far, we have considered garbage collection only of transient servants for transient references. This arrangement simplifies the problem considerably because, in this case, the servant and the CORBA object are almost always the same thing; they are both created at the same time and destroyed at the same time, and using servant managers for transient objects is somewhat unusual. When we consider persistent CORBA objects, however, it becomes difficult even to decide what garbage collection should mean, let alone how to implement it.

Consider a persistent CORBA object representing a person. The object could keep a record of personal details in a database. Clearly, person objects have long life cycles, typically measured in decades. If we want garbage collection for CORBA objects, we must decide what garbage collection actually means. In particular, if we have a servant representing a person object in memory and decide to garbage-collect the servant, the question arises whether destroying the servant should also destroy the persistent database record of the person. For persons, the answer is most likely "no." The fact that the servant is destroyed does not necessarily mean that the persistent record, which represents the

523

IT-SC book: Advanced CORBA® Programming with C++

CORBA object, should also be destroyed. After all, the fact that we have reclaimed a servant to free some memory does not mean that the corresponding person has died.

Looking at objects with a shorter life span, it becomes more difficult to make a clear-cut decision about whether to destroy only the servant or both it and the CORBA object. For example, we may have document objects that represent documents in an archive. Typically, when clients "lose interest" in a document, we want to reclaim the servant for a document object but retain the persistent state of the document. For example, the attention span of most people for doing their taxes is quite short. However, the tax office has a much longer attention span and may well develop interest in a particular document some years after the last client has used it. On the other hand, sooner or later, the statute of limitations expires and we want to garbage-collect not only the servant for the document but also its persistent state. To make matters worse, when the time has come to destroy the document, there may be no servant in existence to remind us that it is time to destroy it.

The preceding examples show that the meaning of garbage collection is highly dependent on each application's requirements. In some cases, to garbage-collect an object means to reap its servant. In other cases, both servant and persistent state must be destroyed, and in yet still others, the circumstances change over time.

12.8.1 The Pacific Ocean Problem

Let us make a simplifying assumption for a moment by stating that to garbage-collect a CORBA object always means to destroy both the servant (if one exists) and the persistent state for the object. What we would like then is that no explicit call to destroy be necessary to make an object disappear. Instead, we would like the object to hang around for as long as clients are interested in it and to automatically disappear after the last client loses interest. Unfortunately, it is generally impossible to know when that time has arrived.

Consider the following scenario: You are stranded on an island in the Pacific Ocean, with a CORBA server as your only link to the rest of the world (you can reply to CORBA messages, but you cannot send them). Being desperate to get home, you decide to create a persistent SOS object in your CORBA server. You write the stringified IOR for your object on a piece of paper, put it into a bottle, and, having carefully inserted the cork, you toss the bottle into the ocean.

The bottle floats around for a few months and eventually washes ashore in Australia, where it is found by someone strolling along the beach. Luckily, the finder of your bottle knows all about CORBA, de-stringifies the object reference, contacts your object to learn about your predicament, and comes to the rescue.

Contrived as this example is, it illustrates an important point: because CORBA permits persistent references to propagate by uncontrollable means, there is no way of knowing whether or not an IOR is still of interest to some client. In the preceding scenario, the

524

IT-SC book: Advanced CORBA® Programming with C++

IOR continues to be of interest while it is floating in the Pacific Ocean, and the finder of the bottle has every right to expect a CORBA invocation via the IOR to reach your SOS object.

Of course, we do not normally store object references in the Pacific Ocean. However, an equivalent action is to write a stringified reference into a file, to send a stringified reference in an e-mail message, or to bind a reference in the Naming Service (see Chapter 18). The semantics of persistent references make it impossible to safely garbage-collect an object. We could decide to destroy an object at any time without warning, but that might leave a client with a dangling reference. The next time that client used the reference, it would get an OBJECT_NOT_EXIST exception.

12.8.2 Referential Integrity

Dangling references fall under the broader topic of referential integrity. A system of CORBA objects and their IORs has referential integrity if there are no dangling references (references without objects) and there are no orphaned objects (objects that cannot be contacted via a reference). As an analogy, the Web would exhibit referential integrity if there were no broken links and if every page could be reached from some starting point by traversing some sequence of links. Clearly, it is difficult to maintain referential integrity in a heterogeneous distributed system that spans enterprise and administrative boundaries; random failures that compromise referential integrity are unavoidable.

One way to deal with lack of referential integrity is to live without it. In real life, we cope with lack of referential integrity all the time. For example, when people dial a telephone number and get a "no such number" message (the equivalent of a dangling reference), they do not throw up their hands in despair. Instead, they have a number of fallback behaviors to recover from the problem (such as using the phone book or calling directory assistance).

In CORBA, the equivalent fallback behavior is not to rely on references to work at all times but to dynamically reacquire them when they fail. However, the effort required to implement such fallback behavior is prohibitive for applications. For example, both transactions and garbage collection can be effectively used to guarantee referential integrity and to provide fallback behavior in a system. But unless such features are provided by the underlying platform, they might as well not exist.

12.8.3 The Future of Garbage Collection

This section has raised more questions than it has answered. The problem of distributed garbage collection is largely unsolved and belongs firmly in the research area, at least for general-purpose object models such as CORBA's. The point of this discussion is to illustrate the deep issues we encounter when we start to consider what it means to destroy a servant or a CORBA object and how we would decide which to destroy. We also hope that we have shown enough about these problems to make you wary if a member of your

525

IT-SC book: Advanced CORBA® Programming with C++

next project suggests that you "just implement a simple garbage collector." Unless you can define precisely how such a collector would work, you should hold any such suggestion firmly at arm's length.

12.9 Summary

This chapter presents approaches to managing the life cycle of objects. The OMG Life Cycle Service offers one possible approach, but because of the problems associated with this service, you may be better off creating non-standard interfaces that preserve type safety. The Evictor pattern offers a simple and effective way to limit memory consumption in servers, and that is the key to creating servers that scale to large numbers of objects. In addition, the Evictor pattern provides an effective and transparent way to garbage-collect your servants. The more general topic of garbage collection of CORBA objects is largely unsolved because it is difficult to reconcile with the CORBA object model as well as application semantics.

526