Try OpenEdge Now
skip to main content
Application Migration and Development Guide
Migrating AppServer and WebSpeed Applications : ABL application code migration : Migrating AppServer operating modes
 

Migrating AppServer operating modes

In the classic OpenEdge AppServer, the operating modes for session-managed client connections is determined in the AppServer configuration. The possible operating modes for session managed connections are state-reset, state-aware, and stateless. For session-free client connections, the operating mode is always state-free. Each classic AppServer instance only runs in only one model. You must start multiple AppServers if you want to support multiple session models and operating modes.
The three operating modes in the classic AppServer produced different requirements for implementing session-managed client connections. In some session-managed modes the session's client request context is preserved between client requests because the client was bound to a single ABL session. While other session-managed models resulted in the ABL application having to manually manage client request context in an external store because each request would execute in a different ABL session. When a client uses the session-free model, the ABL application always manually manages client request context in an external store because all client requests execute in a different ABL session.
In PAS for OpenEdge, the client continues to connect using the session-managed or session-free models, which results in the same client-side behavior as in the classic AppServer. However, the session model is simplified in PAS for OpenEdge, since now there is only one supported connection model, HTTP/S. By removing all other connection models, the session models (now called application models) become simply session-managed or session-free, where any single instance of a PAS for OpenEdge is capable of supported both types simultaneously.
A PAS for OpenEdge session-managed connection is CONDITIONALLY bound to the same ABL session based on the setting of the SESSION:SERVER-CONNECTION-BOUND-REQUEST attribute. Depending on this setting, the optimizations of the multi-session agent provide you with the resource scaling of the classic AppServer's stateless operating mode with the performance and simplicity of session context management of the state-reset and state-aware operating modes. This provides you with the best of both worlds. When the ABL application requires maximum scalability at the request level, or actual concurrent execution of client requests, the PAS for OpenEdge session-free model operates with the same behavior as the classic AppServer running in the state-free operating mode.
With PAS for OpenEdge merging all of the classic AppServer's session-managed modes, there are some changes in when a PAS for OpenEdge session's event procedures execute compared to the corresponding AppServer's configuration procedures. Most changes are transparent. However, in some cases, you must make adjustments if you want your ABL sessions on the server to execute event procedures with exactly the same behavior as configuration procedures on the AppServer.
The following tables compare configuration procedure execution in the classic AppServer and event procedure execution in PAS for OpenEdge:
Table 1. Session-managed event procedures
Procedure
Classic AppServer
PAS for OpenEdge
Comments
Startup
Always
Always
No change ; run persistent
Shutdown
Always
Always
No change
Connect
Always
Always
No change ; run persistent
Disconnect
Always
Always
No change
Activate
Never(1) ; Conditional(2)
Conditional
PAS for OpenEdge follows classic stateless behavior, as long as
Deactivate
Never(1) ; Conditional(2)
Conditional
PAS for OpenEdge follows classic stateless behavior, as long as SESSION:SERVER-CONNECTION-BOUND = FALSE
Table 2. Session-free event procedures
Procedure
Classic AppServer
PAS for OpenEdge
Comments
Startup
Always
Always
No change
Shutdown
Always
Always
No change
Connect
Never
Never
No change
Disconnect
Never
Never
No change
Activate
Conditional(3)
Conditional
PAS for OpenEdge follows classic state-free behavior, as long as SESSION:SERVER-CONNECTION-BOUND = FALSE
Deactivate
Conditional(3)
Conditional
PAS for OpenEdge follows classic state-free behavior, as long as SESSION:SERVER-CONNECTION-BOUND = FALSE
1. Classic AppServer state-reset and state-aware operating modes never execute Activate or Deactivate event procedures.
2. Classic AppServer stateless operating mode always executes Activate and Deactivate procedures unless the client is in a bound state.
3. Classic AppServer state-free operating mode always executes Activate and Deactivate procedures unless the client is in a bound state.
When a PAS for OpenEdge client connects using the session-managed application model, by default, server sessions execute requests from this client in the unbound state, similar to the classic stateless operating mode. As on the classic AppServer, you can change the client connection to the bound state by having the client run a remote persistent procedure or by having the server session set the SESSION:SERVER-CONNECTION-BOUND-REQUEST attribute to TRUE. So, to emulate the behavior of the classic AppServer state-reset and state-aware operating modes, you need to set this attribute appropriately in the Connect and Disconnect event procedures of the PAS for OpenEdge instance. In addition, to emulate the classic AppServer state-reset operating mode, you need to execute QUIT as the last statement of the Disconnect procedure.
When a PAS for OpenEdge client connects using the session-free application model, server sessions also execute requests from this client in the unbound state, similar to the classic state-free operating mode. As on the classic AppServer, you can change the client connection to the bound state by having the client run a remote persistent procedure, but also as on the classic AppServer, the session-managed SESSION handle attributes have no function. For example, setting the SESSION:SERVER-CONNECTION-BOUND-REQUEST attribute to TRUE in a server session running in the unbound state has no effect. You can only know that the connection is bound by querying the SESSION:SERVER-CONNECTION-BOUND attribute. And, as in the case of the classic AppServer, Progress Software recommends that you never have PAS for OE clients execute remote persistent procedures to make a session-free connection bound.
So, if you are migrating an application from a classic stateless or state-free AppServer, your application should require no ABL code changes to achieve the same behavior on PAS for OE.
The following sections detail any changes that might be required to match your particular classic AppServer behavior.
* Migrating classic state-reset operating mode
* Migrating classic state-aware operating mode
* Migrating classic stateless operating mode
* Migrating classic state-free operating mode