On this page:

Object Adapter State Transitions

An object adapter has a number of processing states:

 

The distinction Holding vs Active applies only to requests dispatched through endpoints configured on the object adapter. It does not apply to requests received from bidirectional connections, nor does it apply to collocated dispatches (unless you disable collocation optimization).

An object adapter configured with a router accepts only requests received over the (bidirectional) connection to the router, and collocated dispatches.

Changing Object Adapter States

The ObjectAdapter interface offers operations that allow you to change the adapter state, as well as to wait for a state change to be complete:

module Ice
{
    local interface ObjectAdapter
    {
        // ...

        void activate();
        void hold();
        void waitForHold();
        void deactivate();
        void waitForDeactivate();
        void isDeactivated();
        void destroy();

        // ...
    }
}

The operations behave as follows:

Placing an adapter into the holding state is useful, for example, if you need to make state changes in the server that require the server (or a group of servants) to be idle. For example, you could place the implementation of your servants into a dynamic library and upgrade the implementation by loading a newer version of the library at run time without having to shut down the server.

Similarly, waiting for an adapter to complete its transition to the inactive state is useful if your server needs to perform some final clean-up work that cannot be carried out until all executing requests have completed.

Note that you can create an object adapter with the same name as a previous object adapter, but only once destroy on the previous adapter has completed.

See Also