Release 10.1A: OpenEdge Application Server:
Developing AppServer Applications

> ## State-reset operating mode

> When OpenEdgeŽ sends a client application’s connection request to an AppServer that is running in state-reset operating mode, the AppServer broker connects the client application directly to one of the agents in its AppServer agent pool. The connected AppServer agent remains dedicated to the client application for the life of the connection.

> Between connections, OpenEdge reinitializes the AppServer session to its initial state. This is the state it is in immediately after the AppServer agent is started and after all startup parameters are processed.

> Note: State-reset operating mode is conceptually similar to the operation of AppServers prior to Progress Version 9.

> ##### General AppServer-client interaction

> The general interaction between a state-reset AppServer and client proceeds as follows:

> 1. The client connects to the AppServer broker with or without the help of a NameServer, which provides the address of the broker from a list of AppServers that support a specified application service.

> Note: The algorithm the NameServer uses to choose the broker depends on whether the NameServer is configured for load balancing. For more information, see the "Load balancing and session models" section.

> 2. The AppServer broker connects the client to an available AppServer agent, which is initialized to its initial startup state, with any database connections and context removed that were initialized by any client previously connected to this agent. The broker is then available to accept a connection request from another client.

> 3. The client invokes an application service request (synchronously or asynchronously).

> 4. The connected agent executes the request and returns the results to the client.

> 5. The client handles the results of the application service request and either invokes another request as in Step 3 or disconnects from the AppServer as in Step 6.

> 6. When the client no longer requires the application service, it disconnects from the AppServer agent and cleans up after its connection to the application service, making the AppServer agent available to handle another client connection.

> The number of available simultaneous client connections to a state-reset AppServer corresponds to the number of AppServer agents that it can startup and manage at one time.

> ##### Connection management

> When the AppServer receives a connection request, the AppServer broker chooses an AppServer agent that is not currently dedicated to some other client application’s connection. If all AppServer agents are unavailable, the AppServer broker might create another AppServer agent for the connection, or it might return an error. The result depends on how many AppServer agents are running and the values of various configuration settings.

> When the client application disconnects from its AppServer agent, the AppServer agent notifies the AppServer broker that it is now available to service another client application connection.

> Note: In AppServers prior to Progress Version 9, the AppServer broker terminates the disconnected AppServer agent.

> To help an AppServer session perform common connection tasks, such as user authentication, you can configure a Connect procedure that runs for each connection request and a Disconnect procedure that runs for each disconnection request. For more information on these procedures, see Chapter 2, " Programming the AppServer."

> ##### Performance considerations

> Because an AppServer running in state-reset operating mode dedicates an AppServer agent to each client connection, the connected client is guaranteed of having each request handled immediately by the AppServer. Assuming that the general process load on the AppServer platform is light enough, this means that the client can expect relatively fast response time from the AppServer.

> However, throughput in a state-reset connection tends to drop as client load increases, because the number of dedicated AppServer agents available to handle client connections is necessarily limited by the number of AppServer agents that can be started on the AppServer machine.

> ##### Context management

> Because each AppServer agent is dedicated to a client connection, the AppServer session maintains all session context between client requests. Thus, for example, any global values or database connections that you set in remote procedures remain available for the life of the connection or until you change them during some remote procedure call.

> In between connections, an AppServer session running in state-reset operating mode resets its context to the initial state. This initial state is its context after the AppServer agent first starts and after all AppServer agent startup parameters take effect, including databases connections.

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095