Ok, so CORBA_Object_release takes care of the client side. This isn't enough, because, as Elliot Lee pointed out, to state the point slightly differently:
On Tue, 20 Apr 1999, Svanberg Liss wrote: > Btw, what does CORBA_Object_duplicate & CORBA_Object_release do > server? Nothing.So, what do you do on the server side? Elliot answered this, too:
> and... hmm, what kind of call does destroy the object in the server when > release doesn't? You PortableServer_POA_deactivate_object(poa, objid) to tell the POA not to take any more requests for the specified objid.Let's take a lok at what this means in terms of actual code. If you run orbit-idl --skeleton_impl foo.idlon your idl file, you will get a file foo-impl.c. Inside of that file, you'll seefunctions like the following:
/* You shouldn't call this routine directly without first deactivating the servant... */ static void impl_CosTransactions_Control__destroy( impl_POA_CosTransactions_Control * servant, CORBA_Environment * ev) { POA_CosTransactions_Control__fini((PortableServer_Servant) servant, ev); g_free(servant); }Where it says "You shouldn't call this routine directly without first deactivating the servant...", it means that you should call PortableServer_POA_deactivate_object() on the servant first.
FIXME: I don't understand what POA_CosTransactions_Control__fini does here; how is it different from PortableServer_POA_deactivate_object? Anyway, this is the final step you take after your object is deactivated; you can then free the POA servant struct which you created in your factory (or wherever.)