What is the recommended operating mode for the AppServer?

What are the benefits of using the AppServer in stateless or state-free mode?

The benefits listed below for stateless mode generally apply to state-free mode as well. Because state-free mode maintains only a logical rather than a physical connection between client and AppServer (with certain specific exceptions), the context management capabilities of stateless mode are not available in state-free mode.

Stateless processing works well when:

• Each individual request to the AppServer can be processed separately, or with minimal context to maintain between requests.
• There are no persistent procedures that need to be executed remotely.

Programming can be more complex for a stateless AppServer, but the overall application performance can be better. Progress provides features to save context between requests, but these must be individually programmed.

Context is maintained between requests, but because the broker assigns a request to any available Application Server process, the context available is uncertain. Therefore, context between requests and connections must be maintained programmatically and outside of the Application Server process.

Why manage context in stateless mode

Unlike the other two operating modes, remote client requests in stateless or state-free mode are assigned to any available Application Server process. This means that, by default, the context available to a client request is not predictable. With some effort using the context management tools provided with the AppServer, it is possible to develop a context management scheme for a stateless AppServer similar to those available from the other modes. This provides the benefits of context continuity between client requests as well as the higher throughput and better scalability of stateless mode.

A context database may also be used, either alone or in combination with the SERVER-CONNECTION-CONTEXT attribute (available in stateless operating mode only), to maintain context information. In this case, write context information to the context database instead of, or in addition to, storing the contents of the SERVER-CONNECTION-CONTEXT attribute in memory. Include a connection ID as a field in the database; store the value of the SERVER-CONNECTION-ID attribute in it if using stateless mode. (The SERVER-CONNECTION-ID attribute is not available in state-free mode; attempts to use it will raise a warning message on the server). This provides a key to find and load the context for the correct client connection when making a client request.

When not to use stateless Mode

• Use state-reset to maintain a connection to the Application Server process and its context or to always have a particular initial state available for client requests. State-reset is appropriate for many applications.  It is the most straightforward mode for programming. 
• Use state-reset for converting Version 8 AppServer applications, State-reset works in a compatible way with legacy (Version 8) code, so it provides the easiest migration path.  Use state-reset to maintain existing V8 code if upgrading to one of the new OpenEdge releases.  However, keep in mind that state-reset does not offer the benefits of state-aware or stateless.
• Use state-aware to initialize something for all clients to connect to.  This could include connections to databases, loading temp-tables for static data, or starting persistent procedures for utility programs. Use state-aware to keep a temp-table open to populate it with information from several sources before processing.