However, you need to use bound connections on a stateless AppServer with care. If client connections to a stateless AppServer are bound the majority of the time, the stateless operating mode is not a good choice, especially under heavy client load. In this case, the stateless AppServer is effectively running much like a state-aware or state-reset AppServer where each AppServer agent remains effectively dedicated to one client for the duration of the bound connection.
In some cases, if most of the context that you need to maintain between requests is minimal, but occasionally you need to maintain a large amount of context for a small portion of the application, then stateless might still be an appropriate choice. In that case, you can temporarily make the connection bound by having the client run a remote persistent procedure and delete shortly after, or by setting the SERVER-CONNECTION-BOUND request attribute to TRUE within the AppServer session and setting it to FALSE shortly after.
Note: You might want to run all of your requests on a bound connection, if you use a briefly-bound approach. In a briefly-bound approach, you reserve all context maintenance to a few requests on the bound connection during processing that is free of user interaction or other client-blocking activity. Then, you make the connection unbound before performing any blocking or other intensive activity (think time) on the client. With briefly-bound connections, the AppServer remains free to service other clients most of the time and with fewer AppServer agent required.
In addition, all requests for a stateless AppServer go through the AppServer broker. Thus, two messages are sent for each request. One message travels between the client and the AppServer broker and the other message travels between the AppServer broker and the AppServer agent. However, because a state-aware or state-reset AppServer maintains a direct connection between the client and the AppServer agent, only one message is sent per request. Under these conditions, your only choice, to both maintain AppServer context and increase the response of the AppServer to client connections, might be to use state-aware or state-reset and to add additional computing resources at the AppServer site to sustain the client connections.
