Activate and Deactivate procedures

The classic AppServer provides ABL session Activate and Deactivate event procedures that enable you to manage the initialization and cleanup of a client's request in both unbound session-managed and session-free models. Because of the different connection models for the classic AppServer, the execution and scope of these procedures vary in the AppServer, based on limitations imposed by the an application's architecture. The properties that control these event procedures use the prefix srvr, which reflects their identification with server (agent) processes. Each AppServer agent is a single ABL session that runs as a single OS process (AVM).

The srvrActivateProc and srvrDeactivateProc procedures are important if your application is using the classic AppServer's stateless or state-free modes. Those classic AppServer modes require that you manually manage client and session context because each request is executed in a different ABL session. The Activate procedure is run because it restores the context saved at the end of the client's previous request, and the Deactivate procedures is run because it saves the context for use by the client's next request. Because there are no formal connection and disconnection operations in the classic AppServer modes, you must implement your own start/stop client session architecture.

The classic AppServer executes the Activate and Deactivate procedures. The client bound condition relates to the AppServer client being bound to a single ABL session where each client request is guaranteed to execute in that particular ABL session. When the client is bound to a session, there is no requirement for the ABL application code to save and restore context using the Activate and Deactivate procedures because the context persists as long as the session is bound.

Whenever an ABL session is client bound, it will not execute Activate and Deactivate procedures. The classic AppServer's modes influence the client bound condition and the ABL code in the application. The following table helps to illustrate the classic AppServer's behavior:

The stateless and state-free classic AppServer modes can change the state from unbound to bound, and from bound to unbound based on two conditions:

1. The client executes a persistent procedure on the AppServer (stateless or state-free).
   • The Activate procedure executes before the persistent procedure's main block.
   • The client bound state is set after the Activate procedure runs.
   • Because the client bound state exists, the Deactivate procedure does not execute after the persistent procedure's main block executes.
   • Activate or Deactivate procedures do not execute until the client bound state is cleared.
   • The client bound state is cleared when the persistent procedure is deleted by the client, and the Deactivate procedure is executed as part of the delete operation.
2. The classic AppServer ABL code sets SESSION:SERVER-CONNECTION-BOUND-REQUEST to TRUE (stateless only).
   • The Deactivate procedure does not execute at the end of the client request that set the client bound state.
   • Activate or Deactivate procedures do not execute until the client bound state is cleared by the ABL application code running in the classic AppServer.
   • When the AppServer's ABL code clears the client bound state, the Deactivate procedure will execute when the current procedure ends.
   • Normal Activate and Deactivate execution resumes on each subsequent client request after the client bound state is cleared.

Like the classic AppServer, PAS for OpenEdge supports the client bound state, but might require changes to the ABL code to get the same behavior as classic AppServer operating modes when a client is connected with a given application model:

The transitions from bound to unbound and unbound to bound in PAS for OpenEdge follow the same behavior as the classic AppServer for client executed persistent procedures or using the SESSION:SERVER-CONNECTION-BOUND-REQUEST attribute on the server. Likewise, the state changing sequence of PAS for OpenEdge Activate and Deactivate procedures follow the behavior of the changing client bound states for the AppServer. The difference between classic AppServer and PAS for OpenEdge is that to start a server session in the bound state you must change the session-managed Connect event procedure to manually establish the client bound state. When you manually force a client bound state in PAS for OpenEdge, ensure that the client bound state is cleared in the session-managed Disconnect event procedure.

Naming

The classic OpenEdge AppServer properties in ubroker.properties are srvrActivateProc and srvrDeactivateProc.

The corresponding PAS for OpenEdge properties in openedge.properties are sessionActivateProc and sessionDeactivateProc.

In both servers, these properties are implemented as parameter-name=value pairs.