3.7.2 Tobj_ServantBase Interface
The Tobj_ServantBase interface inherits from the
PortableServer::RefCountServantBase class and defines
operations that allow a CORBA object to assist in the management of
its state in a thread-safe manner. Every implementation skeleton
generated by the IDL compiler automatically inherits from the
Tobj_ServantBase class. The
Tobj_ServantBase class contains two virtual methods,
activate_object() and
deactivate_object(), that may be optionally
implemented by the programmer.
Whenever a request comes in for an inactive CORBA object, the
object is activated and the activate_object() method
is invoked on the servant. When the CORBA object is deactivated,
the deactivate_object() method is invoked on the
servant. The timing of deactivation is driven by the
implementation’s activation policy. When the
deactivate_object() method is invoked, the TP
Framework passes in a reason code to indicate why the call was
made.
These methods support the development of a multithreaded server application:
-
TobjServantBase::_add_ref() -
TobjServantBase::_is_reentrant() -
TobjServantBase::_remove_ref()Note:
Tobj_ServantBase::activate_object()andTobj_ServantBase::deactivate_object()are the only methods that the TP Framework guarantees will be invoked for CORBA object activation and deactivation. The servant class constructor and destructor may or may not be invoked at activation or deactivation time (through theServer::create_servantcall for C++). Therefore, the server application code must not do any state handling for CORBA objects in either the constructor or destructor of the servant class.The programmer does not need to use a cast or reference to
Tobj_ServantBasedirectly. TheTobj_ServantBasemethods show up as part of the skeleton and, therefore, in the implementation class for a servant. The programmer may provide definitions for theactivate_objectanddeactivate_objectmethods, but the programmer should never make direct invocations on those methods; only the TP Framework should call those methods.