Realistically, will removing the session state request lock actually affect the site

Vote count:

0

I've been playing with different session state providers for ASP.Net recently and have come up with what appears to be the best (performance and implementation wise).

Using http://ift.tt/MvjVVc

This works marvelously and is very simple to implement. The only issue is that it forces the request lock - so the browser has to wait if there is a request open. This is fine a lot of the time, but when you end up on some long-running process and the user wants to give up, the user is left hanging until the long running process finishes.

Now - this can be resolved by removing the lock from the provider. This is as easy changing the lines where lock = true to lock = false, and altering the update so it takes no notice of "&& state.Locked && state.LockId == lockId"

Panic! Clearly this goes against how session state was intended, and in terms of thread safety it's a frightening prospect. But...in a lot of sites we've built, session state is rarely used for anything more complex than "which user id is currently active" - which gets written very rarely. It may be used to transfer (large) data between 2 pages, and it may be used to store the odd setting. ...in a lot of cases thread safety is rarely going to be a problem, so is the performance trade off actually worth it, or is removing the lock and venturing out to get a significantly more responsive site worth the risk?

asked 29 secs ago

Paul

3,561