3.2.2.2 Self Deactivation
Just as it is possible to preactivate an object with the
process
activation policy, it is possible to request
the deactivation of an object with the process
activation policy. The ability to preactivate and the ability to
request deactivation are independent; regardless of how an object
was activated, it can be deactivated explicitly.
A method in the application can request (via
TP::deactivateEnabl
e) that the object be deactivated.
When TP::deactivateEnable
is called and the object is
subsequently deactivated, no guarantee is made that subsequent
invocations on the CORBA object will result in reactivation in the
same process as a previous activation. The association between the
ObjectId
and the servant exists from the activation of
the CORBA object until one of the following events occurs: (1) the
shutdown of the server process or (2) the application calls
TP::deactivateEnable
. After the association is broken,
when the object is invoked again, it can be reactivated anywhere
that is allowed by the Oracle Tuxedo configuration parameters.
There are two forms of TP::deactivateEnable
. In the
first form (with no parameters), the object currently executing
will be deactivated after completion of the method in which the
call is made. The object itself makes the decision that it should
be deactivated. This is often done during a method call that acts
as a "signoff" signal.
The second form of TP::deactivateEnable
allows a
server to request deactivation of any active object, whether it is
the object that is executing or not; that is, any part of the
server can ask that the object be deactivated. This form takes
parameters identifying the object to be deactivated. Explicit
deactivation is not allowed for objects with an activation policy
of transaction
, because such objects cannot be safely
deactivated until the end of a transaction.
In the TP::deactivateEnable
call, the TP Framework
calls the servant’s deactivate_object
method.
Exactly when the TP Framework invokes
deactivate_object
depends on the state of the object
to be deactivated. If the object is not currently in execution, the
TP Framework deactivates it before returning to the caller. The
object might be currently executing a method; this is always the
case for TP::deactivateEnable
with no parameters
(since it refers to the currently executing object). In this case,
TP::deactivateEnable
is not told whether the object
was deactivated immediately or not.
Note:
TheTP::deactivateEnable(interface, object id, servant) method
can be used to deactivate an object. However, if that object is currently in a transaction, the object will be deactivated when the transaction commits or rolls back. If an invoke occurs on the object before the transaction is committed or rolled back, the object will not be deactivated. To ensure the desired behavior, make sure that the object is not in a transaction or ensure that no invokes occur on the object after the TP::deactivateEnable()
call until the transaction is complete.
Parent topic: Application-controlled Activation and Deactivation