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