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.
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.
If you are going to use the client cursor engine then often it’s a good idea to disconnect your recordset…
Disconnected Recordsets
The normal procedure for using the Client Cursor Engine is to open your recordset with client side cursors and then disconnect it from the data source. This causes the CCE to pull all of your data out of the data source and effectively marshal it by value to your client.
How to package lots of standard functionality into a CListBox derived class.
The problem
Several times now I’ve found the need for a pair of list boxes that are linked. Items can appear in either of the list boxes, but not in both. Items can be moved between list boxes, and have processes performed on them. Their order within the list boxes can often be shuffled.
The first time I ended up with all of the code to do this spread throughout the message handlers of the enclosing dialog box.
Localise design decisions by writing key application functionality as pluggable COM objects. When the requirements change you just write a new plug in…
Introduction
Sometimes it’s difficult to see the wood for the trees. You know that using COM is good, but how can you use it? How do you write an app that uses COM? How do you get from IApe and all the text book examples to something in the real world?
It’s rare that code can be viewed as a black box for reuse. If you include design choices and dependencies as valid parts of the code’s interface then it’s easier to explain why reusing nontrivial code is often harder than writing it from scratch.
One of the problems that I find when I’m trying to reuse some code is that even if the code is documented well, or written in a style where little documentation is needed, it can rarely be used as a black box.
Making the ADO Client Cursor Engine believe that your rowset is updateable involves jumping through a few extra hoops…
Client Cursor Engine Updates
It turns out that supporting updates through the client cursor engine is relatively easy. Discovering that it’s relatively easy was extremely difficult. An article that was recently added to the MSDN gives complete and full information on what a rowset needs to support for updates via the CCE to be possible.
The ATL OLE DB Provider templates only seem to support read-only rowsets, and making them support updating of data isn’t as easy as you’d expect!
Cursors everywhere
First it’s worth clearing up some confusion about client and server side cursors and our rowset. Normally selecting either client or server side cursors is a simple choice between network traffic and local storage. Server side cursors are physically located with the data and in the case of most OLE DB providers that’s probably on the far end of a network connection to your database server.
