| Previous | Table of Contents | Next |
Servant managers are associated with POAs. A servant manager supplies a POA with the ability to activate objects on demand
when the POA receives a request targeted at an inactive object. A servant manager is registered with a POA as a callback object,
to be invoked by the POA when necessary. An application server that activates all its needed objects at the beginning of execution
does not need to use a servant manager; it is used only for the case in which an object must be activated during request processing.
The ServantManager interface is itself empty. It is inherited by two other interfaces, ServantActivator and ServantLocator.
The two types of servant managers correspond to the POA’s RETAIN policy (ServantActivator) and to the NON_RETAIN policy (ServantLocator).
The meaning of the policies and the operations that are available for POAs using each policy are listed under the two types
of derived interfaces.
Each servant manager type contains two operations, the first called to find and return a servant and the second to deactivate
a servant. The operations differ according to the amount of information usable for their situation.
ServantManager is a local interface. A ServantManager object must be local to the process containing the POA objects it is
registered with.
11.3.5.1 Common Information for Servant Manager Types
The two types of servant managers have certain semantics that are identical.
The incarnate and preinvoke operation may raise any system exception deemed appropriate (for example, OBJECT_NOT_EXIST if
the object corresponding to the Object Id value has been destroyed).
Note – If a user-written routine (servant manager or method code) raises the OBJECT_NOT_EXIST exception, the POA does nothing
but pass on that exception. It is the user’s responsibility to deactivate the object if it had been previously activated.
The incarnate and preinvoke operation may also raise a ForwardRequest exception. If this occurs, the ORB is responsible for
delivering the current request and subsequent requests to the object denoted in the forward_reference member of the exception.
The behavior of this mechanism must be the functional equivalent of the GIOP location forwarding mechanism. If the current
request was delivered via an implementation of the GIOP protocol (such as IIOP), the reference in the exception
11-24 Common Object Request Broker Architecture (CORBA), v3.0.3 March 2004
should be returned to the client in a reply message with LOCATION_FORWARD reply status. If some other protocol or delivery
mechanism was used, the ORB is responsible for providing equivalent behavior, from the perspectives of the client and the
object denoted by the new reference.
If the ForwardRequest exception is raised anywhere else, it is passed through the ORB as a normal user exception.
If a ServantManager returns a null servant (or the equivalent in a language mapping) as the result of an incarnate or preinvoke
operation, the POA returns the OBJ_ADAPTER system exception with standard minor code 7 as the result of the request. If the
ServantManager returns the wrong type of servant, it is indeterminate when that error is detected. An ORB that chooses to
detect the error shall raise OBJ_ADAPTER with standard minor code 2; an ORB that does not explicitly check for this error
condition likely raises BAD_OPERATION with standard minor code 2 or a MARSHAL exception (with unspecified minor code) at the
time of method invocation.