Hi Nadya,

If I were running a small Intranet app using a web based front-end being feed by a web server, and I had a good idea about how many connections would be necessary, and the number of concerrent users was static, I would go with persistent connections. Also, there is now connection pooling that allows a number of users to share a single connection handle. This really conserves resources in a persistent connection setting.

If I were running a shopping cart app via the web, and there could be thousands of user each needing a connection handle, like ebay for example, I would open the connection when the submit button was clicked, capture any input to the back-end table, and then disconnect. Since connection handles are allowcated via a configuration setting, the server set aside enough memory, buffers, etc to handle the connection setting per the configuration which could range anywhere from like 32 to thousands. If the configuration setting is changed to increase the max connections, then the computer would allowcate additional resources needed to run each additional connection.

With a setting of 32 connection, the server would easity handle maybe 300 concurrent users because they would all not be hitting the submit button at the same time, and the connection handle would only be used for the faction of a second it takes to complete the tranaction. Once the disconnect is executed, the connection handle is released and become available for the next user. If the server runs out of connections, an error message would be issue about no more connections. It would be very likely a connection would become available the next time the user clicked his browser submit button. No harm would occur from the error, since the user is mostly disconnected from the server anyway.

LelandJ