3.2.1 Activation Policy

State management is provided in the TP Framework by the activation policy. This policy controls the activation and deactivation of servants for a particular IDL interface (as opposed to the creation and destruction of the servants). This policy is applicable only to CORBA objects using the TP Framework.

The activation policy determines the default in-memory activation duration for a CORBA object. A CORBA object is active in a POA if the POA's active object map contains an entry that associates an object ID with an existing servant. Object deactivation removes the association of an object ID with its active servant. You can choose from one of three activation policies:method (the default), transaction, or process.

Note:

The activation policies are set in an ICF file that is configured at OMG IDL compile time. For a description of the ICF file, refer to the Implementation Configuration File (ICF) section.

The activation policies are described below:

• method (This is the default activation policy.)

  The activation of the CORBA object (that is, the association between the object ID and the servant) lasts until the end of the method. At the completion of a method, the object is deactivated. When the next method is invoked on the object reference, the CORBA object is activated (the object ID is associated with a new servant). This behavior is similar to that of an Oracle Tuxedo stateless service.

• transaction

  The activation of the CORBA object (that is, the association between the object ID and the servant) lasts until the end of the transaction. During the transaction, multiple object methods can be invoked. The object is activated before the first method invocation on the object and is deactivated in one of the following ways:

  • If a user-initiated transaction is in effect when the object is activated, the object is deactivated when the first of the following occurs: the transaction is committed or rolled back, or the server is shut down in an orderly fashion. The latter is done using either the tmshutdown or tmadmin command. These commands are described in the Oracle Tuxedo Command Reference online document.
  • If a user-initiated transaction is not in effect when the TP object is activated, the TP object is deactivated when the method completes.
  The transaction activation policy provides a means for an object to vote on the outcome of the transaction prior to the execution of the two-phase commit algorithm. An object votes to roll back the transaction by calling Current.rollback_only() in the Tobj_ServantBase::deactivate_object method. It votes to commit the transaction by not calling Current.rollback_only() in the method.

  Note:

  This is a model of resource allocation that is similar to that of an Oracle Tuxedo conversational service. However, this model is less expensive than the Oracle Tuxedo conversational service in that it uses fewer system resources. This is because of the Oracle Tuxedo ORB’s multicontexted dispatching model (that is, the presence of many servants in memory at the same time for one server), which makes it possible for a single server process to be shared by many concurrently active servants that service many clients. In the Oracle Tuxedo system, the process would be dedicated to a single client and to only one service for the duration of a conversation.
• process

  The activation of the CORBA object begins when it is invoked while in an inactive state and, by default, lasts until the end of the process.

  Note:

  The TP Framework API provides an interface method (TP::deactivateEnable) that allows the application to control the timing of object deactivation for objects that have the activation policy set to process. For a description of this method, see the section TP::deactivateEnable().