In the physical model, components that are placed on the middle-tier server and communicate with the client computer should be stateless. If a component on the middle-tier server maintained state (that is, retained information between calls from the client), these components would need to maintain information on every client that made a request to the component. As the number of clients making requests increased, the information that would need to be stored in memory would increase until the server ran out of memory. This would not be a scalable solution.
If components on the middle-tier and database servers do not maintain state, they can quickly perform a service for one client and then perform a service for another client. This feature works even better with a technique called just-in-time activation (JITA). With JITA, a component becomes active immediately before it is used. Once the component has been activated, it will quickly perform a service and then deactivate. As soon as the component has finished with one client, it is available for another client. These components can be built so that they require a minimum amount of time to perform their services. They reside in memory for only a brief time to service each client. Because these components are stateless, they will not require any memory usage between client calls. Thus, a stateless component that uses JITA will use the absolute minimum amount of server resources while still servicing a large number of clients. These types of stateless components can scale very well.
It is possible to create stateful server components that communicate with the client. The most common example is stateful ASP. Using state for ASP-based systems that never have more than 100 possible users, such as a small departmental intranet application, might be appropriate. Using state in large-scale ASP-based Web applications, however, will seriously degrade performance of the system and should be avoided.