I’ve just finished posting some more reprints from back in 2001 when I was working on CORBA systems with C++ and Java. The articles mostly compare CORBA to COM and show why providing a reference counted server object lifetime management system is harder than it appears. 1 - CORBA - Reference Counting. Adding reference counting to CORBA objects isn’t as easy as it first seems. 2 - CORBA - More Reference Counting.
When a CORBA server allows its clients to create and destroy objects one of the recommended ways to handle the object lifetime issues is using the Evictor Pattern. In The Evictor Pattern we solved the problem for C++ servers, here we do the same for Java servers. The problem Due to the way that CORBA deals with object lifetime issues you may find it necessary to have the server control the lifetime of objects created on the server by the client.
One way of making a reference counted implementation more robust is to run the keep-alive protocol yourself. We demonstrate this option here. The problem In the previous article we developed a strategy where the server would destroy objects if the client hadn’t used them for a certain period of time. This protects the server from leaked objects and is necessary because CORBA doesn’t provide a keep alive mechanism. If a client has a valid reason to hold onto an object and not do anything with it then the only way that they can keep the object active in the server is to poke it every now and then - even if they have no reason to make a method call on the object.
Since CORBA doesn’t really support reliable reference counting implementations we’ll compare one of the recommended methods of servant life-time management with our reference counted iteration interface. The problem If you can’t trust the runtime to make sure that your clients behave themselves, then the server has to take object lifetime issues into its own hands. The evictor pattern does just that. The server decides how long your object can live, when the server decides you’ve had enough it simply destroys your object for you and your next call fails… It doesn’t matter if you forget to release your objects when you’re done, they’ll get cleaned up eventually.
A CORBA style method of enumeration can be seen in the iteration interfaces on the CORBA Naming Service. Given the code we’ve already written for the enumeration interface we can easily implement an iteration interface as well as (or, more likely, instead of). Setting the scene As we pointed out in a previous article, reference counting without a keep-alive protocol is not especially robust and objects may be leaked on the server.
CORBA provides sequences as a way of returning collections of items from an method call. The problem with just using unbounded sequences is that the client has no control over how many items it receives as a result of the call. COM gets around this problem using the IEnum style interfaces that allow a client to control how it accesses the items in a collection. Setting the scene As we pointed out in the last article, reference counting without a keep-alive protocol is not especially robust and objects may be leaked on the server.
At the end of the second article we have developed a self contained reference counting implementation that appears to work. Unfortunately, it’s still far from reliable as CORBA doesn’t provide the level of support for reference counting that’s built into COM. In this article we discuss the problem and the various CORBA methods for controlling server object lifetime. The problem In the last two articles we’ve worked our way towards implementing a COM style reference counting system in CORBA.
Although we managed to develop a working solution in the first CORBA reference counting article the results were ugly and fragile. In this article we attempt to clean things up a little and, in doing so, get intimate with the Portable Object Adapter and its Servant Managers. The problem In the previous article we started out with the goal of adding COM style reference counting to a CORBA object. We found that the obvious COM way to do this didn’t work due to the way that the default behavior for the POA prevents us from deleting a servant object from within a method call on that servant object.
We’ve been developing code on Windows and Unix for quite some time, but most of the distributed component work we’ve been involved in has been done using COM. That’s changing now as clients have more requirements for Unix based component solutions. We’re currently evaluating CORBA ORBs and learning how the CORBA way of doing things differs from the COM way. The first difference that we came across was the way that CORBA servers deal with object lifetime issues.