Skip navigation.

CORBA Programming Reference

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Implementation Configuration File (ICF)

The BEA Tuxedo CORBA TP Framework application programming interface (API) provides callback methods for object activation and deactivation. These methods provide the ability for application code to implement flexible state management schemes for CORBA objects.

State management is the way you control the saving and restoring of object state during object deactivation and activation. State management also affects the duration of object activation, which influences the performance of servers and their resource usage. The external API of the TP Framework includes the activate_object() and deactivate_object() methods, which provide a possible location for state management code. Additionally, the TP Framework API includes the deactivateEnable() method to enable the user to control the timing of object deactivation. The default duration of object activation is controlled by policies assigned to implementations at OMG IDL compile time.

While CORBA objects are active, their state is contained in a servant. This state must be initialized when objects are first invoked (that is, the first time a method is invoked on a CORBA object after its object reference is created) and on subsequent invocations after objects have been deactivated.

While a CORBA object is deactivated, its state must be saved outside the process in which the servant was active. When an object is activated, its state must be restored. The object's state can be saved in shared memory, in a file, in a database, and so forth. It is up to the programmer to determine what constitutes an object's state, and what must be saved before an object is deactivated and restored when an object is activated.

You can use the Implementation Configuration File (ICF) to set activation policies to control the duration of object activations in each implementation. The ICF file manages object state by specifying the activation policy. The activation policy determines the in-memory activation duration for a CORBA object. A CORBA object is active in a Portable Object Adapter (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.


ICF Syntax

ICF syntax is as follows:

[#pragma activation_policy method|transaction|process]
[#pragma transaction_policy never|ignore|optional|always]
[#pragma concurrency_policy user_controlled|system_controlled]
[#pragma retry_policy never|always]
[Module module-name {]
implementation [implementation-name]
implements (module-name::interface-name);
[activation_policy (method|transaction|process);]
[transaction_policy (never|ignore|optional|always);]
[concurrency_policy (user_controlled|system_controlled);]
[retry_policy (never|always)];


The four optional pragmas allow you to set a specific policy as the default policy for the entire ICF for all implementations that do not have an explicit activation_policy, transaction_policy, concurrency_policy, or retry_policy statement. This feature relieves the programmer from having to specify policies for each implementation and/or allows overriding of the defaults.

Module module-name

The module-name variable is optional if it is optional in the OMG IDL file. This variable is used for scoping and grouping. Its use must be consistent with the way it is used inside the OMG IDL file.


This variable is optional and is used as the name of the servant or as the class name in the server. It is constructed using interface-name with an _i appended if it is not specified by the programmer.

implements (module-name::interface-name)

This variable identifies the module and the interface to which the activation policy and the transaction policy apply.


For a description of the activation policies, see Activation Policy.


For a description of the transaction policies, see Transaction Policies.


For description of the concurrency policies, see Parallel Objects.


For a description of the retry policy, see IIOP Client Failover.


Sample ICF File

Listing 2-1 shows a sample ICF file.

Listing 2-1 Sample ICF

module POA_University1
implementation CourseSynopsisEnumerator_i
activation_policy ( process );
transaction_policy ( optional );
implements ( University1::CourseSynopsisEnumerator );

module POA_University1
implementation Registrar_i
activation_policy ( method );
transaction_policy ( optional );
implements ( University1::Registrar );

module POA_University1
implementation RegistrarFactory_i
activation_policy ( process );
transaction_policy ( optional );
implements ( University1::RegistrarFactory );



Creating the ICF File

You have the option of either coding the ICF file manually or using the genicf command to generate it from the OMG IDL file. For a description of the syntax and options for the genicf command, see the BEA Tuxedo Command Reference.

See Also

Steps for Creating a BEA Tuxedo CORBA Server Application


Skip navigation bar  Back to Top Previous Next