3.2.3.2 Special Cases

There are two techniques an application can use to alter the normal TP Framework use of servants. The first has to do with obtaining a servant and the second has to do with disposing of the servant.

The application can alter the “obtaining” mechanism by using explicit preactivation. In this case, the application creates and initializes a servant before asking the TP Framework to declare it activated. Once such a servant has been turned over to the TP Framework (by the TP::create_active_object_reference call), that servant is treated by the TP Framework just like every other servant. The only difference is in its method of creation and initialization.

The application can alter the “disposing” mechanism by taking the responsibility for disposing of a servant instead of leaving that responsibility with the TP Framework. Once a servant is known to the TP Framework (through Server::create_servant, ServerBase::create_servant_with_id, or TP::create_active_object_reference), the TP Framework’s default behavior is to remove that servant itself. In this case, the application code must no longer use references to the servant after deactivation.

However, the application may tell the TP Framework not to dispose of the servant after the TP Framework deactivates it. Taking responsibility for a servant is done on an individual servant basis, not for a whole class of servants, by calling Tobj_ServantBase::_add_ref with a parameter identifying the servant.

Note:

In applications written using Oracle Tuxedo release 8.0 or later, use the Tobj_ServantBase::_add_ref method instead of the TP::application_responsibility() method. Unlike the TP::application_responsibility() method, the add_ref() method takes no arguments.

The advantage of the application taking responsibility for the servant is that the servant does not have to be created anew. If obtaining the servant is an expensive proposition, the application may choose to save the servant and reuse it later. This is especially likely to be true for servants for preactivated objects, but is true in general. For example, the next time the TP Framework makes a call on Server::create_servant orServerBase::create_servant_with_id, the application might return a previously saved servant.

Additionally, once an application has taken responsibility for a servant, the application must take care to remove the servant (using Tobj_ServantBase::_remove_ref) when the servant is no longer needed, that is, when the reference count drops to zero, the same as for any other C++ instance. For more information about how the _remove_ref() method works, see Tobj_ServantBase::_remove_ref().

For more information on writing single-threaded and multithreaded server applications, see Creating CORBA Server Applications.