Try OpenEdge Now
skip to main content
Developing AppServer Applications
Programming the AppServer : Using AppServer configuration procedures : Activate and Deactivate procedures : Deactivate procedure
 
Deactivate procedure
The Deactivate procedure executes immediately after remote procedure and delete procedure requests when the connection is in the unbound state. A typical use of the Deactivate procedures is to store connection context using an application-specific context database or using the SERVER-CONNECTION-CONTEXT attribute on the SESSION handle. For more information, see Managing stateless connection context. Using the SERVER-CONNECTION-ID attribute, you can uniquely identify (key) the context in the context database. You can then gather the context identified with the connection and store it in the context database or marshall it into the SERVER-CONNECTION-CONTEXT attribute.
In either state-free or stateless operating mode, you can also store connection context keyed on the value of the ClientContextId property of the Progress.Lang.OERequestInfo class. From the Activate (or any other AppServer) procedure, you can access this property on the OERequestInfo object that is returned by the CURRENT-REQUEST-INFO attribute on the SESSION handle. For more information, see Managing state-free and stateless client context.
You can specify the name of an AppServer Deactivate procedure using the OpenEdge Explorer or OpenEdge Management or by setting the srvrDeactivateProc property in the AppServer properties file (ubroker.properties). If you specify this procedure, it accepts no parameters and runs as a non-persistent procedure after the request executes, but before any response is returned to the client. Also, the Deactivate procedure runs only if the connection is unbound when the request completes execution.
A stateless connection can be in the unbound or the bound state when a request is initiated and can change to the opposite state before the request completes execution. If the connection ends up in the bound state during execution of the request, the Deactivate procedure does not run when the request completes. However, if the connection ends up in the unbound state, the Deactivate procedure runs even if the original request completes with some ABL termination condition (ERROR, QUIT, or STOP).
After a delete procedure request, the Deactivate procedure runs only if the connection is unbound. The connection can become unbound only if both of the following are true:
*The deleted procedure was the last instantiated remote persistent procedure for the connection
*The SERVER-CONNECTION-BOUND-REQUEST attribute has a value of FALSE
For more information on how stateless connections transition between bound and unbound states, see Managing stateless connection context.
Note: The Deactivate procedure only runs following remote procedure and delete procedure requests. It does not run in response to new connection or disconnection requests.
For the purposes of error handling, only return values from the request (or any executed Activate procedure) are passed to the client. Any return values generated by the Deactivate procedure, itself, are ignored.