11.2.7 Implicit Activation

   A POA can be created with a policy that indicates that its objects may be implicitly activated. This policy, IMPLICIT_ACTIVATION, also requires the SYSTEM_ID and RETAIN policies.

   When a POA supports implicit activation, an inactive servant may be implicitly activated in that POA by certain operations that logically require an Object Id to be assigned to that servant. (IMPLICIT_ACTIVATION does not disallow explicit activation; instead, it enables both implicit and explicit activation.)

   Implicit activation of an object involves allocating a system-generated Object Id and registering the servant with that Object Id in the Active Object Map. The interface associated with the implicitly activated object is determined from the servant (using static information from the skeleton, or, in the case of a dynamic servant, using the _primary_interface() operation).

   The operations that support implicit activation include:

• The POA::servant_to_reference operation, which takes a servant parameter and returns a reference.

• The POA::servant_to_id operation, which takes a servant parameter and returns an Object Id.

• Operations supported by a language mapping to obtain an object reference or an Object Id for a servant. For example, the _this() servant member function in C++ returns an object reference for the servant.

• Implicit conversions supported by a language mapping that convert a servant to an object reference or an Object Id.

   The last two categories of operations are language-mapping-dependent.

   If the POA has the UNIQUE_ID policy, then implicit activation will occur when any of these operations are performed on a servant that is not currently active (that is, it is associated with no Object Id in the POA's Active Object Map).

   If the POA has the MULTIPLE_ID policy, the servant_to_reference and servant_to_id operations will always perform implicit activation, even if the servant is already associated with an Object Id. The behavior of language mapping operations in the MULTIPLE_ID case is specified by the language mapping. For example, in C++, the _this()servant member function will not implicitly activate a MULTIPLE_ID servant if the invocation of _this() is immediately within the dynamic context of a request invocation directed by the POA to that servant; instead, it returns the object reference used to issue the request.

   Note – The exact timing of implicit activation is ORB implementation-dependent. For example, instead of activating the object immediately upon creation of a local object reference, the ORB could defer the activation until the Object Id is actually needed (for example, when the object reference is exported outside the process).

   11.2.8 Multi-threading

   The POA does not require the use of threads and does not specify what support is needed from a threads package. However, in order to allow the development of portable servers that utilize threads, the behavior of the POA and related interfaces when used within a multiple-thread environment must be specified.

   Specifying this behavior does not require that an ORB must support being used in a threaded environment, nor does it require that an ORB must utilize threads in the processing of requests. The only requirement given here is that if an ORB does provide support for multi-threading, these are the behaviors that will be supported by that ORB. This allows a programmer to take advantage of multiple ORBs that support threads in a portable manner across those ORBs.

   The POA’s processing is affected by the thread-related calls available in the ORB: work_pending, perform_work, run, and shutdown.

   11.2.8.1 POA Threading Models

   The POA supports three models of threading when used in conjunction with multi-threaded ORB implementations; ORB controlled, single thread and main-thread behavior. The three models can be used together or independently. All can be used in environments where a single-threaded ORB is used.

   The threading model associated with a POA is indicated when the POA is created by including a ThreadPolicy object in the policies parameter of the POA’s create_POA operation. Once a POA is created with one model, it cannot be changed to the other. All uses of the POA within the server must conform to that threading model associated with the POA.

   11.2.8.2 Using the Single Thread Model

   Requests for each single-threaded POA are processed sequentially. In a multi-threaded environment, upcalls made by this POA to servants shall not be made concurrently. This provides a degree of safety for code that is multi-thread-unaware.

   Note – In a multi-threaded environment, requests to distinct single-threaded POAs may be processed concurrently.

   The POA will still allow reentrant calls from an object implementation to itself, or to another object implementation managed by the same POA.

   11.2.8.3 Using the ORB Controlled Model

   The ORB controlled model of threading is used in environments where the developer wants the ORB/POA to control the use of threads in the manner provided by the ORB. This model can also be used in environments that do not support threads.

   In this model, the ORB is responsible for the creation, management, and destruction of threads used with one or more POAs.

   11.2.8.4 Using the Main Thread Model

   Requests for all main-thread POAs are processed sequentially. In a multi-threaded environment, all upcalls made by all POAs with this policy to servants are made in a manner that is safe for code that is multi-thread-unaware.

   If the environment has special requirements that some code must run on a distinguished "main" thread, servant upcalls will be processed on that thread. (See Section 4.2.5, “Thread-Related Operations,? on page 4-10.)

   Note – Not all environments have such a special requirement. If not, while requests will be processed sequentially they might not all be processed by the same thread.

   11.2.8.5 Limitations When Using Multiple Threads

   There are no guarantees that the ORB and POA will do anything specific about dispatching requests across threads with a single POA. Therefore, a server programmer who wants to use one or more POAs within multiple threads must take on all of the serialization of access to objects within those threads.

   There may be requests active for the same object being dispatched within multiple threads at the same time. The programmer must be aware of this possibility and code with it in mind.