Keywords: doc

Next: Activation Mode Persistent Up: Activation Modes Previous: Activation Modes

### Activation Mode Shared

Shared servers can serve any number of object instances, which is probably the most widely used approach. The account server from section 3.3.3 is an example for a shared server. Lets look at the code again:

     1: // file account_server2.cc
     2:
     3: #include "account.h"
     4:
     5: class Account_impl : virtual public Account_skel
     6: {
     7:   // unchanged, see section "MICO Application"
     8:   // ...
     9: };
    10:
    11:
    12: int main( int argc, char *argv[] )
    13: {
    14:   // ORB initialization
    15:   CORBA::ORB_var orb = CORBA::ORB_init( argc, argv, "mico-local-orb" );
    16:   CORBA::BOA_var boa = orb->BOA_init( argc, argv, "mico-local-boa" );
    17:
    18:   Account_impl* server = new Account_impl;
    19:
    20:   boa->impl_is_ready( CORBA::ImplementationDef::_nil() );
    21:   orb->run ();
    22:   CORBA::release( server );
    23:   return 0;
    24: }

After creating the implementation repository entry for the account server using the `imr` utility the account server stays inactive until the account client wants to bind to an object with repository id `IDL:Account:1.0`. The BOA daemon recognizes that there are no active account objects and consults the implementation repository for servers that implement objects with repository id `IDL:Account:1.0`. It will find the account server and run it. The account server in turn creates an account object in line 18, which will be announced to the BOA daemon. The server uses `impl_is_ready()` to tell the BOA daemon that it has completed initialization and is prepared to receive method invocations. The BOA daemon in turn finds the newly created account object and answers the bind request from the client with it. Finally `run()` is called on the ORB to start processing events.

`run()` will wait for requests and serve them as they arrive until the `deactivate_impl()` method is called, which deactivates the server. Calling the ORB method `shutdown()` will make `run()` return and the account server will exit. If method invocations arrive after the server has exited the BOA daemon will restart the server. See section 4.3.5 for details on restaring servers.

There are many reasons for calling `deactivate_impl()`. For example we could augment the account objects interface by a management interface that offers a method `exit()` that will shut down the account server:

      // account.idl
      interface Account {
        ...
        void exit ();
      };

The implementation of the `exit()` method would look like this:

      // account.idl
      class Account_impl : virtual public Account_skel {
        ...
      public:
        ...
        virtual void exit ()
        {
          CORBA::BOA_var boa = _boa();
          CORBA::ORB_var orb = _orb();
          boa->deactivate_impl (CORBA::ImplementationDef::_nil());
          orb->shutdown (TRUE);
        }
      };

Note that we passed a NIL `ImplementationDef` to `deactivate_impl()` as well as to `impl_is_ready()`. Usually the implementation repository has to be searched to find the entry for the server and pass this one. When passing NIL the entry will be searched by the BOA. `shutdown()` has a `boolean wait` parameter which controls whether the ORB should immediately stop processing events (`wait=FALSE`) or wait until all pending requests have completed (`wait=TRUE`).

Next: Activation Mode Persistent Up: Activation Modes Previous: Activation Modes