If you application has a large amount of context to manage between each request, then state-reset or state-aware are appropriate choices. Stateless is not a good choice because of the complexity and performance impact of managing this connection context through the Activate and Deactivate procedures for each request.

If there is a large amount of context that you need to establish for each connection that is independent of the user who is running the client application (for example, loading a temp-table with static data), and only a small portion of the context is user specific, then state-aware might be a better choice then state-reset. This is true because with state-aware, you only need to establish the connection-independent context once, in the Startup procedure. You generally establish the user-specific context within the Connect procedure, using the user ID and password information provided by the client application.

The Startup procedure is not available for state-reset. Thus, both the connection-independent context and the user-specific context have to be established within the Connect procedure. Under these conditions, the time it takes to connect to a state-aware AppServer can be significantly shorter than the time it takes to connect to a state-reset AppServer because all of the connection-independent context is established before the client actually attempts to connect to the AppServer.