Building Distributed
Applications
Using the Progress AppServer


Stateless Operating Mode

Unlike state-reset or state-aware, an AppServer running in stateless operating mode does not dedicate any Application Server process to a client connection. Instead, all Application Server processes remain generally available to execute remote procedure requests from all connected client applications.

When a client connects to an AppServer that is running in stateless operating mode, the Application Broker maintains the connection between itself and the client. The Application Broker can then dispatch each remote procedure request from the client to any available Application Server process to execute. Because any Application Server process that executed a previous request from this client might not be available, the Application Server process that handles subsequent requests might be different.

NOTE: The name of this operating mode (“stateless”) refers to the lack of context that AppServer sessions automatically maintain between client requests. However, stateless operating mode does support additional mechanisms that you can use to maintain some context between requests, as described in the following sections.

Connection Management

By default, all connections on a stateless AppServer are unbound—that is, all Application Server processes are available to handle requests from any client connection. As long as an Application Server process is not currently handling a client request, it can handle requests from any connected client. However, at any time during the handling of a client request, a client connection can become bound—that is, the Application Server process handling the request becomes available to handle requests only from the client it is currently servicing. While a connection is bound, all requests from the connected client are handled by the same Application Server process. In the same way it became bound, at any time during the handling of a client request, a bound connection can become unbound, at which point requests from the connected client can be handled by any available Application Server process.

In general, then, a stateless Application Server process is available to handle a client request as long as it is not currently processing a client request and as long as it is not waiting on a bound connection. If a stateless AppServer has no Application Server processes available to handle requests, all requests are queued at the Application Broker until an Application Server process becomes available.

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 Programming the AppServer."

A connection in the unbound state can transition to the bound state in two ways:

Note that it is the successful instantiation of a remote persistent procedure that forces the connection to transition from the unbound state to the bound state. If a client fails in its attempt to instantiate a remote persistent procedure on an unbound connection, the connection remains unbound.

For more information on managing connection states on a stateless AppServer, see Programming the AppServer."

Performance Considerations

Because a stateless AppServer passes requests from connected clients to any available Application Server process, the number of clients that a single AppServer instance can handle using this operating mode is relatively high. That is, a relatively small number of Application Server processes can support many client connections. If you never set connections to the bound state, a stateless AppServer can make maximum use of its available Application Server process resources to handle client requests. This operating mode thus maximizes throughput for large numbers of clients, especially when they maintain short connections.

Context Management

An AppServer running in stateless operating mode does not reset its session context between client connections. Instead, it maintains most all context created in an AppServer session until a particular Application Server process terminates or the context is changed by some procedure running in the AppServer session.

For an AppServer running in stateless operating mode you can also configure Startup and Shutdown procedures that run in every AppServer session when it starts up and shuts down. You can use these procedures to establish and discard run-time context that the AppServer maintains in common for all connections. For more information on the Startup and Shutdown procedures, see Programming the AppServer."

Using a bound connection, the AppServer maintains all session context created between client requests (similar to a state-aware AppServer), because the bound connection maintains one Application Server process to execute all requests for the same connected client until you reset the connection to the unbound state.

Using an unbound connection, the AppServer does not automatically guarantee that context created during a remote procedure request will be available when the same client makes the next request. As noted in a previous section, this is because a stateless AppServer cannot guarantee that the same Application Server process will handle the next request. However, you can still maintain context created between requests from a connected client, but only by explicitly saving the created context using one of several mechanisms. Two such mechanisms specially supported for stateless AppServers include:

For more information on these mechanisms, see Programming the AppServer."

As noted in a previous section Progress does not automatically delete any AppServer session context between requests to a stateless AppServer. The only exception to this is if a client application disconnects from a stateless AppServer while it has remote persistent procedures active in the AppServer session. In that case, Progress does automatically delete the active remote persistent procedures before disconnecting the client application.


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