Web Framework applications use web service calls to access the server process. For this to work efficiently, it is recommended to always enable Process Pooling. Here's why:
Before a web service request can be handled, the web application must be loaded and initialized and all data tables must be opened. In legacy ASP Web applications, this process occurred on a session basis. Session management is built into Microsoft's IIS/ASP server and was created to provide limited persistence over the Internet. The Java Servlet model provides a similar capability. The first time a browser makes a request to a web application a session is started. Future requests from that browser would use the same session. A session remains active until a specified inactivity period has occurred, at which time the session is closed. If the browser makes another request to the same site after a session has closed a new session is created.
Web Applications running without process pooling uses these sessions to determine when the app should be loaded and unloaded. When a session starts, a Web Application instance is created (loaded, initialized, tables opened). This process is uniquely assigned to the session instance. The browser assigned to the session has sole access to that instance. When the session is closed, the Web Application instance is closed.
However, persistence is not that useful in web applications and even less so in web services. It's not the way the Internet works. A web application has no real way of knowing when a user is really done. For example a user may visit your site, request a page and make no other requests to your site for 15 minutes. Is the user finished? When should the application close? What is the appropriate time out period? The answer to all of these questions is, you just don't know. For this reason, most professionally written web applications do not rely on session persistence. Each page request is treated as an isolated and standalone event. All information required to request a page and process information is passed to and from the client. Web Application has always worked that way; you should never try to rely on session persistence. All our wizards generate code that does not rely on persistence, and none of our samples rely on persistence.
Process Pooling better fits the suggested web application model and will do a dramatically better job of managing resources. Why?
A Web Application process is assigned on a request basis and not on a session basis.
The Web Application processes are kept in a pool of running instances.
When a browser makes a request, the Web Application Server goes to its process pool and assigns the request to a Web Application process. When the response is completed, the Web Application process is returned to the pool. Since the Web Application process is already loaded, the process of attaching and detaching a Web Application process to a request is very fast. And, since a properly written request should be fast, the number of requests that can be serviced by a single Web Application process is much higher. The net result is faster performance with less resource usage. Processes are not being constantly loaded and unloaded and tables are not being constantly opened and closed.
When used in conjunction with Load Balancing, process pooling also provides protection against server failure (a process can be taken from a "pool" that spans multiple servers).
When you create applications that do not rely on persistence, you can use process pooling without any required programming changes. Since multiple users may now share the same process, events are provided during the attach and detach process to make sure that all data is properly initialized and de-initialized. Normally, you will not need to use these since the default initialization and de-initialization behavior of the application will do this for you. For example, all the Web Application samples work with process pooling without any required changes.
Important Concepts and Options