Sometimes it would be nice to be able to use a simple C++ object as a sink for Connection Point notifications. This article shows you how.
Sinking connection points in C++ objects.
Many COM objects provide events to their clients by means on Connection Points. A Connection Point is a generalised method of allowing clients to register a COM interface so that the object can notify them of things that they may be interested in.
This example COM component provides three COM objects for using the Win32 Mailslot IPC mechanism. The component may be useful if you need to communicate from VB using Mailslots. However, the reason I wrote it was to demonstrate creating a COM component in C++ that integrates well with VB and can fire asynchronous events.
Overview
The COM component consists of an object factory which is used to create instances of the Mailslot manipulation objects.
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.
