RE: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ
- From: Kevin <Kevin@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 9 Jan 2008 18:58:03 -0800
On further inspection, EnableSessionState="ReadOnly," truly is readonly (the
documentation hinted that you could still run into reader/writer conflicts,
so I was hoping the semantics of ReadOnly was just that it didn't lock the
session during the request and required you to put locks around session
reads/writes).
So, I am back to my original questions about how to implement the workaround
that you suggested...
Thanks!
"Kevin" wrote:
It seems like one option would be just to set EnableSessionState to ReadOnly.
in the @Page directive:
http://msdn2.microsoft.com/en-us/library/ms178581.aspx
I think this would work for me, unless I have a WebFarm, a SQLServer Session
State provider, and the requests hit two different servers without session
afinity in the load balancer. Any other potential issues?
Kevin
"Kevin" wrote:
Wow, that's a bit surprising, although it makes some sense. I would have
thought there would at least be an option to make the default provider
"optimistic," and then require all session state modification to have a lock
around it. It seems a little bit overkill to lock the session for an entire
request?
Are there any known problems with a customer session manager? And by session
manager, do you mean a custom SessionStateStoreProviderBase? Do you know of
any existing implementations? All I'm really holding in the session is an ID
of the user, so it's not something I want to stop user-concurrent requests
for.
Thanks for your help!
Kevin
"bruce barker" wrote:
this is by design.
the lock is on session state. only one request (to the same session) is
allowed at the same time. you should not see this if session is turned off
for the page, or the requests come from two different users (sessions
actually).
the reason for this is because there is no locking code for accessing an
object in session.
you can get around this by writing your own session manager, and not
honoring the lock requests. then change all code that references a session
object to be thread safe. for out of proc session manager you will need to
maintain a current use count.
-- bruce (sqlwork.com)
"Kevin" wrote:
Hi, I am running Win2K3 Server Enterprise Edition SP2, and I have logged that
requests are not running concurrently. I created an IHttpModule and printed
debug on every event, and found that when one long running request is
processing, another request comes in and pauses between PostMapRequestHandler
and AcquireRequestState. When the original request completes, this second
request continues.
I have found this article describing the same problem and a fix using an
undocumented registry key SessionStateLockedItemPollInterval in
HKLM\Software\Microsoft\ASP.NET:
http://forums.iis.net/t/1147300.aspx
First, I am running a current version of IIS, and Windows, so theoretically
this should be fixed, but the weirdest thing happens. So, I put in this
registry value, and everything is fixed, until I do some action in my app
(don't understand what), and for the rest of the life of the AppDomain, it
reverts to old serialized behavior. If I restart the computer, again it works.
My test case is simple. There is slow.aspx:
public partial class slow : System.Web.UI.Page
{
public override void ProcessRequest(HttpContext context)
{
// [LOG here]
base.ProcessRequest(context);
}
protected void Page_Load(object sender, EventArgs e)
{
// [LOG here]
Thread.Sleep(8000);
Response.Output.Write("SlowResponse, threadid={0}",
Thread.CurrentThread.ManagedThreadId);
}
}
Then there is fast.aspx:
public partial class fast : System.Web.UI.Page
{
public override void ProcessRequest(HttpContext context)
{
// [LOG here]
base.ProcessRequest(context);
}
protected void Page_Load(object sender, EventArgs e)
{
// [LOG here]
Response.Output.Write("FastResponse, threadid={0}",
Thread.CurrentThread.ManagedThreadId);
}
}
On my local IIS or VS web server, this works fine of course. I run
slow.aspx, and after a few seconds, run fast.aspx -- it should display
immediately while slow.aspx spins.
On my remote IIS, except for the "initial" instances with the registry
value, I run slow.aspx, and a few seconds later, fast.aspx, and fast.aspx
only comes back after slow.aspx finishes. And of course, looking at the
logging, I have confirmed this is not just a remote connection issue, but I
can actually see the BeingRequest come in for fast.aspx, and it only hits
AcquireRequestState after slow.aspx hits EndRequest.
This problem is baffling, and the fact that the registry key only
sporadically works, I'm not sure what to do. I am trying to upgrade .NET 2.0
to SP1 and see if that works....
Please help! Serialized access web servers would suck! :-) [of course, I
know it is some kind of bug]
By the way, I am currently using InProc for the session store.
- References:
- IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS
- From: Kevin
- RE: IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS
- From: bruce barker
- RE: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ
- From: Kevin
- RE: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ
- From: Kevin
- IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS
- Prev by Date: Re: Incorrect syntax near 'nvarchar'.
- Next by Date: Get control
- Previous by thread: RE: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ
- Next by thread: Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS
- Index(es):
Relevant Pages
|
