The classic AppServer provides ABL session Activate and Deactivate event procedures that allow 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-specified 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 restores the context saved at the end of the client's previous request, and the Deactivate procedures 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 are required to implement your own start/stop client session architecture.
The classic AppServer conditionally executes the Activate and Deactivate procedures based on the binding state of the client, which can potentially be confusing. 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 via 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 cease to execute Activate and Deactivate procedures. The classic AppServer's modes influence the client bound condition as well as the ABL code in the application. The following table will help understand the classic AppServer's behavior:
Table 6. Comparing Activate and Deactivate procedures between AppServer and PAS for OE
Operating mode
Starting bound state
Ending bound state
Can change bound state?
State-reset
Bound
Bound
No
State-aware
Bound
Bound
No
Stateless
Unbound
Unbound
Yes
State-free
Unbound
Unbound
Yes
The stateless and state-free classic AppServer modes can change 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 will execute prior to 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.
No further Activate or Deactivate procedures 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 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.
No further Activate or Deactivate procedures are executed until the client bound state is cleared by the ABL application code running in the 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, which are:
Application model
Starting bound state
Ending bound state
Can change bound state?
Session-managed
Unbound
Unbound
Yes
Session-free
Unbound
Unbound
Yes
The transitions from bound to unbound and unbound to bound in PAS for OpenEdge follow precisely 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 precisely 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 requires modification of the session-managed Connect event procedure to manually establish the client bound state. When manually forcing a client bound state in PAS for OpenEdge, you should 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.
The Activate procedure will execute prior to the persistent procedure's main block.