Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

I guess you could use EnableSessionState="ReadOnly". You should be able to
avoid locking.

It's not always about "thread" safety.
Just imagine a scenario when customer clicks "Confirm order" button. And
"double clicks" it.

Correctly written program would submit the order and then clear out shopping
cart. So when second click (it was waiting for first one to be processed)
comes in, shopping cart is empty and person is not charge twice and order
not submitted twice

With concurrent approach those double clicks will be processed
simultaneously and order will be submitted twice.
So although every single operation (updating DB, charging CC... ) is thread
safe, the whole process is not.

George.




"Kevin" <Kevin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:2E592DB0-8809-4C5F-BC36-B9AC0DECA1D0@xxxxxxxxxxxxxxxx
Thanks for the reply, I am interested in working around this design
because
all I store in the session is an integer ID which I map to internal
constructs that are thread safe. How can I work around this limitation yet
still have EnableSessionState = true? Bruce mentioned a custom provider
which
doesn't adhere to the lock. Are there any examples of this?

Thanks!
Kevin

"George Ter-Saakov" wrote:

Different users will not block each other. Only same user who is hitting
the
same session.
You can not have 2 simultaneous request for the same session. And it's
actually a good thing and done for your own benefits.



George




"Kevin" <Kevin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:256B60AA-1AA7-453F-BEF8-75C57928BED5@xxxxxxxxxxxxxxxx
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.





.