>The SQL was a *very* basic 'SELECT.....' no updates, no joins etc. As mentioned above I think the *only* safe solution is to apply the Application.Lock() before opening the connection and to keep it in place until the connection is closed. Given the overhead of implementing the lock it may well be that overall performance is as good as, if not better, than wrapping each SQL execution in its own lock. And upping the process count in the application pool seems to improve performance.
>
>In my test running the 'safe' solution reduced the number of hits handled by about 15% - hopefully your server would have enough 'headroom' to make that acceptable.

Well, the problem with the lock is if an unexpected situation happens, while the lock is in progress, thus the hit would not terminate as expected, this would mean that the application will then be locked forever. Is that the case?

Also, I was interesting to get your feedback on the fact that 160 application locks could be done per second. Do you consider that this would make sense?