>>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?

I'm not sure of this but I'd hope/assume that the lock is scoped to the thread so it shouldn't be a problem. I'll try to test....

>
>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?

100 not 160 (6000+/min)
The server I used for the test was not a particularly hi-spec machine by current standards - single 3.something Intel processor, 1GB RAM - but it was doing nothing other than servicing the stress test POSTS
Regards,
Viv