Blogs

A “generic” AVL Tree, from the dark days before templates… The code here is some of my first C++. Back in 1991 C++ was still pretty new. Looking back at my early C++ is better than looking back at my early C. At least my early C++ just looked like OKish C with some odd keywords… How do you index a data structure that keeps changing? The game world for the multi-user adventure system I was writing between ‘89 and ‘94 was stored in a network of interconnected nodes.

In 1989 I taught myself C to write an adventure game, the code’s fairly bad, but 10 year’s later, the game’s still quite cool! A very simple adventure game… Over 10 years ago I taught myself to program in C. I wanted to write a program to help me customise the multi-user adventure game I was playing at the time. In MUD II when you reached the exalted rank of Wizard you could create your own rooms and objects.

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. 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.