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

Is it possible that your application restarts all the time?

Have folowing code in your global.asax, you will need to create
SendEmail(msg, ssubj, to) function so every time your app restarts you will
get an email.

George.


protected void Application_End(Object sender, EventArgs e)
{
HttpRuntime runtime =
(HttpRuntime)typeof(System.Web.HttpRuntime).InvokeMember("_theRuntime",

BindingFlags.NonPublic

| BindingFlags.Static

| BindingFlags.GetField,

null,

null,

null);
if (runtime == null)
return;
string shutDownMessage =
(string)runtime.GetType().InvokeMember("_shutDownMessage",
BindingFlags.NonPublic
|
BindingFlags.Instance
|
BindingFlags.GetField,
null,
runtime,
null);
string shutDownStack =
(string)runtime.GetType().InvokeMember("_shutDownStack",
BindingFlags.NonPublic
|
BindingFlags.Instance
|
BindingFlags.GetField,
null,
runtime,
null);

//send email to me
SendEmail(String.Format("\r\n\r\n_shutDownMessage={0}\r\n\r\n_shutDownStack={1}",
shutDownMessage,
shutDownStack), "Application Shutdown",
"myemail@xxxxxxxxxxx");
}

George.

"Kevin" <Kevin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:EC9BD1EB-9047-454C-B940-33F6A3045792@xxxxxxxxxxxxxxxx
Yes, I'm sorry, you're right, only one instance, but I see that the Init
method gets called multiple times, sporadically, and sometimes
pInitialized
is false again, so I don't think the example is working as expected, or my
configuration is incorrect. Any ideas?

Thanks,
Kevin

"George Ter-Saakov" wrote:

Looks like you were wrong.
Only one instance of IHttpModule is created per application.

George

"Kevin" <Kevin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E0037365-73A6-414C-8CF5-9683EF3AEC5F@xxxxxxxxxxxxxxxx
One thing I don't understand is that the MSDN MySessionStateModule
IHttpModule stores the Hashtable of session objects in a private member
variable and not a static member variable -- I thought ASP.NET created
a
new
instance of an IHttpModule on every request. The reason I think this is
that
I was having issues implementing this where every a few requests, the
session
would be gone. When I changed the variables to static, things seem to
work
properly.

Any thoughts?
Thanks!

"bruce barker" wrote:

just remeber you will need a lock everytime you access (read or write)
an
object or its properties stored in session.


-- bruce (sqlwork.com)


"Kevin" wrote:

Thanks! That is exactly what I was looking for. I will be careful...
:-)

Thanks again

"George Ter-Saakov" wrote:

I guess, if you really know what you doing, you can write your own
"Session"
Look at this article
http://msdn2.microsoft.com/en-us/library/system.web.sessionstate.sessionstateutility.aspx

Here is excerpt from this article
"The following code example shows a custom session-state module
implementation .......
This application does not prevent simultaneous Web requests from
using the
same session identifier."

Seems to me exactly what you want.


George.

"Kevin" <Kevin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:DDA903F7-8D25-46E4-AA1A-52BD0005B98D@xxxxxxxxxxxxxxxx
Thanks George, I understand the concern, but I can safely have
concurrent
same-user requests in my application. I need to have this
functionality
because I have many very independent and small AJAX requests
executing,
and I
will deal in code with concurrency.

I have tried EnableSessionState="ReadOnly," but then I am not
able
to
write
into the session object. I will do *potentially* do read and
write
into
the
session from all of my pages, so I cannot just have one login
page
with
EnableSessionState=true and the rest with ReadOnly.

Do I have to create some kind of custom session state provider
which
doesn't
have locking? If so, how do I do this?

Thanks!
Kevin

"George Ter-Saakov" wrote:

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.














.