Kbase P96428: Why should you use the appServer in Stateless mode
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/3/2004 |
|
Status: Unverified
GOAL:
Why should you use the appServer in Stateless mode
FACT(s) (Environment):
Progress 9.x
FIX:
Progress recommends using the appServer in stateless mode whenever that is possible. In particular, use stateless mode when individual client calls are not related and minimal information needs to be saved between client requests, or otherwise when you need scalability without loss of performance. Using stateless processing is very convenient when you have a large number of clients and limited hardware. Use stateless processing when you need to add many clients; stateless applications scale up very efficiently and require less hardware to do so than other operating modes.
Stateless processing works well when:
? Each individual request to the AppServer can be processed separately, or with minimal context to maintain between requests.
? You do not have 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 for you to save context between requests, but you must program these yourself.
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 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, you can 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.
You also can use a context database, either alone or in combination with the SERVER-CONNECTION-CONTEXT attribute, 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. Remember to include the connection ID as a field in the database, and store the value of the SERVER-CONNECTION-ID attribute in it. This provides a key so that you can find and load the context for the correct client connection when a making a client request.
When not to use stateless Mode
Use state-reset if you want to maintain a connection to the Application Server process and its context or if you always want to 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 Version 8 code, so it provides the easiest migration path. Use state-reset if you want to maintain existing V8 code as you move to V9. However, keep in mind that state-reset does not offer the benefits of state-aware or stateless.
Use state-aware when you want 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 when you need to keep a temp-table open while you populate it with information from several sources before processing.