POA Policies

A POA is created with a list of POA Policies. They are:

Thread Policy - specifies the threading model to use with the created POA.

ORB_CTRL_MODEL - The ORB is responsible for assigning requests for an ORB controlled POA to threads. In a multi-threaded environment, concurrent requests may be delivered using multiple threads.
SINGLE_THREAD_MODEL - Requests for a single-threaded POA are processed sequentially. In a multi-threaded environment, all upcalls made by this POA to implementation code (servants and servant managers) are made in a manner that is safe for code that is multi-thread-unaware.

Lifespan Policy - specifies the lifespan of objects implemented in the POA.

TRANSIENT - The objects implemented in the POA cannot outlive the process in which they are first created. Once the POA is deactivated, use of any object references generated from it will result in an OBJECT_NOT_EXIST exception.

Note: In the ORB, when the TRANSIENT and USER_ID policies are used together, the object references are persistent (without Server Activation) as long as the POA is started on the same address. This is achieved by using the ORBHost ORB property, or the Transport, Cluster, or Security policies.
PERSISTENT - The objects implemented in the POA can outlive the process in which they are first created.

Persistent objects have a POA associated with them (the POA which created them). When the ORB receives a request on a persistent object, it first searches for the matching POA, based on the names of the POA and all of its ancestors.
Once you register your servers implementing persistent objects, the ORB will automatically do on-demand activation of a process implementing this POA. See Server Activation.
POA names must be unique within their enclosing scope (the parent POA). A portable program can assume that POA names used in other processes will not conflict with its own POA names.

Object Id Uniqueness Policy - specifies whether the servants activated in the POA must have unique object identities.

UNIQUE_ID - Servants activated with that POA support exactly one Object Id.
MULTIPLE_ID - a servant activated with that POA may support one or more Object Ids.

Object Id Assignment Policy - specifies whether Object Ids in the POA are generated by the application or by the ORB.

USER_ID - Objects created with that POA are assigned Object Ids only by the application.
SYSTEM_ID - Objects created with that POA are assigned Object Ids only by the POA. If the POA also has the PERSISTENT policy, assigned Object Ids must be unique across all instantiations of the same POA. See Understanding System Generated Ids.

Servant Retention Policy - specifies whether the created POA retains active servants in an Active Object Map.

RETAIN - The POA will retain active servants in its Active Object Map.
NON_RETAIN - Servants are not retained by the POA.

Note: The NON_RETAIN policy requires either the USE_DEFAULT_SERVANT or USE_SERVANT_MANAGER policies.

Request Processing Policy - specifies how requests are processed by the created POA.

USE_ACTIVE_OBJECT_MAP_ONLY - If the Object Id is not found in the Active Object Map, an OBJECT_NOT_EXIST exception is returned to the client. The RETAIN policy is also required.
USE_DEFAULT_SERVANT - If the Object Id is not found in the Active Object Map or the NON_RETAIN policy is present, and a default servant has been registered with the POA using the set_servant operation, the request is dispatched to the default servant. If no default servant has been registered, an OBJ_ADAPTER exception is returned to the client. The MULTIPLE_ID policy is also required.
USE_SERVANT_MANAGER - If the Object Id is not found in the Active Object Map or the NON_RETAIN policy is present, and a servant manager has been registered with the POA using the set_servant_manager operation, the servant manager is given the opportunity to locate a servant or raise an exception. If no servant manager has been registered, an OBJECT_ADAPTER exception is returned to the client.

Implicit Activation Policy specifies whether implicit activation of servants is supported in the created POA.

IMPLICIT_ACTIVATION - the POA will support implicit activation of servants. IMPLICIT_ACTIVATION also requires the SYSTEM_ID and d policies.
NO_IMPLICIT_ACTIVATION - the POA will not support implicit activation of servants.

Default POA Policy Values

**Table 1:** Default Values for POA Policies.
POA Policy	Default Value
Thread Policy	ORB_CTRL_MODEL
Lifespan Policy	TRANSIENT
Object Id Uniqueness Policy	UNIQUE
Object Id Assignment Policy	SYSTEM
Servant Retention Policy	RETAIN
Request Processing Policy	USE_ACTIVE_OBJECT_MAP_ONLY
Implicit Activation Policy	NO_IMPLICIT_ACTIVATION

Request Processing

By means of combining the Servant Retention Policy and Request Processing Policy, the programmer is able to define a rich number of possible behaviors.

RETAIN and USE_ACTIVE_OBJECT_MAP_ONLY

This combination represents the situation where the POA does no automatic object activation (that is, the POA searches only the Active Object Map). The server must activate all objects served by the POA explicitly, using either the activate_object or activate_object_with_id operation.
RETAIN and USE_SERVANT_MANAGER

This combination represents a very common situation, where there is an Active Object Map and a ServantManager. Because RETAIN is in effect, the application can call activate_object or activate_object_with_id to establish known servants in the Active Object Map for use in later requests. If the POA doesn't find a servant in the Active Object Map for a given object, it tries to determine the servant by means of invoking incarnate in the ServantManager (specifically a ServantActivator) registered with the POA. If no ServantManager is available, the POA raises the OBJECT_ADAPTER system exception.
RETAIN and USE_DEFAULT_SERVANT

This combination represents the situation where there is a default servant defined for all requests involving unknown objects. Because RETAIN is in effect, the application can call activate_object or activate_object_with_id to establish known servants in the Active Object Map for use in later requests. The POA first tries to find a servant in the Active Object Map for a given object. If it does not find such a servant, it uses the default servant. If no default servant is available, the POA raises the OBJECT_ADAPTER system exception.
NON-RETAIN and USE_SERVANT_MANAGER

This combination represents the situation where one servant is used per method call. The POA doesn't try to find a servant in the Active Object Map because the ActiveObjectMap does not exist. In every request, it will call preinvoke on the ServantManager (specifically a ServantLocator) registered with the POA. If no ServantManager is available, the POA will raise the OBJECT_ADAPTER system exception.
NON-RETAIN and USE_DEFAULT_SERVANT

This combination represents the situation where there is one single servant defined for all CORBA objects. The POA does not try to find a servant in the Active Object Map because the ActiveObjectMap doesn't exist. In every request, the POA will invoke the appropriate operation on the default servant registered with the POA. If no default servant is available, the POA will raise the OBJECT_ADAPTER system exception.

Not all combinations of POA policies are valid. See the valid policy combinations.