Server-side deactivation
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 look at what this means in terms of actual code. If you run
orbit-idl --skeleton_impl foo.idl
on your idl file, you will get a file foo-impl.c. Inside of that file,
you will see functions 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.)