A common way to improve the performance of Java code is to cache objects rather than repeatedly create and destroy them. This is especially true when you’re writing middle tier servers that service client requests and return results objects. Implementing a flexible caching scheme in Java is relatively easy, but there are a few things to watch for.
The problem Creating objects in the middle tier that live for only the length of a single client request can be inefficient.
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.
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.
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.
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.
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.
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.
COM+ applications can be complex to configure and there’s no standard way to save that configuration in a form that can be placed under version control. Luckily the COM+ Catalog is accessible by a set of completely scriptable COM objects. These scripts take advantage of this to provide some functionality that should really come as standard.
Scripting the COM+ Catalog
COM+ applications can be complex to configure. This complexity increases as you use more COM+ services.