IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS

  • Thread starter Thread starter Kevin
  • Start date Start date
K

Kevin

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.
 
I have upgraded to .NET SP1 and it is the same problem. It works at first,
but then it degrades back into the unworking state. I have removed the
registry key. Any ideas? How do i report a bug to MS?
 
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 said:
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.
Click to expand...
 
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 said:
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 said:
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.
Click to expand...
Click to expand...
 
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 said:
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 said:
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 said:
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.
Click to expand...
Click to expand...
Click to expand...
 
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 said:
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 said:
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 said:
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)


:

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.
Click to expand...
Click to expand...
Click to expand...
 
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 said:
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.
Click to expand...
 
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 said:
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 said:
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.
Click to expand...
Click to expand...
 
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 said:
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 said:
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 said:
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.
Click to expand...
Click to expand...
Click to expand...
 
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 said:
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 said:
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 said:
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




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.
Click to expand...
Click to expand...
Click to expand...
 
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 said:
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 said:
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 said:
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

:

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




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.
Click to expand...
Click to expand...
Click to expand...
 
Thanks! That is exactly what I was looking for. I will be careful... :-)

Thanks again

George Ter-Saakov said:
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 said:
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 said:
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.




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

:

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




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.
Click to expand...
Click to expand...
Click to expand...
 
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 said:
Thanks! That is exactly what I was looking for. I will be careful... :-)

Thanks again

George Ter-Saakov said:
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 said:
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

:

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.




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

:

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




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.
Click to expand...
Click to expand...
Click to expand...
 
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 said:
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 said:
Thanks! That is exactly what I was looking for. I will be careful... :-)

Thanks again

George Ter-Saakov said:
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.

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

:

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.




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

:

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




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.
Click to expand...
Click to expand...
Click to expand...
 
Looks like you were wrong.
Only one instance of IHttpModule is created per application.

George

Kevin said:
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 said:
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 said:
Thanks! That is exactly what I was looking for. I will be careful...
:-)

Thanks again

:

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.

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

:

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.




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

:

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




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.
Click to expand...
Click to expand...
Click to expand...
 
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 said:
Looks like you were wrong.
Only one instance of IHttpModule is created per application.

George

Kevin said:
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 said:
just remeber you will need a lock everytime you access (read or write) an
object or its properties stored in session.


-- bruce (sqlwork.com)


:

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

Thanks again

:

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.

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

:

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.




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

:

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




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.
Click to expand...
Click to expand...
Click to expand...
 
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",
"(e-mail address removed)");
}

George.

Kevin said:
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 said:
Looks like you were wrong.
Only one instance of IHttpModule is created per application.

George

Kevin said:
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!

:

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


-- bruce (sqlwork.com)


:

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

Thanks again

:

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.

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

:

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.




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

:

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




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.
Click to expand...
Click to expand...
Click to expand...
 
Hi George, I added debug statements to both Application_Start and
Application_End, and I only see one debug line coming out of
Application_Start, as expected. I also added some debug to the MSDN class in
the Init method, and Init gets called more than once, and sometimes
pInitialized is false (and therefore the hash table is different and my
session is not found):

public void Init(HttpApplication app)
{
....
if (!pInitialized)
{
lock (typeof(ConcurrentSessionStateModule))
{
if (!pInitialized)
{
if (Log.Enabled) Log.LogDebug10("Initializing {0}",
this.GetType().Name);

Is it correct that Init is getting called more than once even though
Application_Start only gets called once?

Thanks for your help

George Ter-Saakov said:
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",
"(e-mail address removed)");
}

George.

Kevin said:
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 said:
Looks like you were wrong.
Only one instance of IHttpModule is created per application.

George

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!

:

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


-- bruce (sqlwork.com)


:

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

Thanks again

:

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.

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

:

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.




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

:

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




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);
}
Click to expand...
Click to expand...
Click to expand...
 
What can I say.... I can not get the behavior you are getting.
My Init method is only called once..... I even plugged that Session module
from MSDN....Just make a clean one page application and try to reproduce
that behavior.


Here is couple points to look at, my guess might lead to that behavior

1. Your Init(HttpApplication app) throws an error and Module is never
initializing. Then i think .NET might repeatedly call Init method.

2. Your application is restarting all the time. If you do it in development
then everytime you recompile project it restarts application.


George.
 
Back
Top