Concurrent Requests from Same Session

The Serialization is to keep the session data consistent between requests.
The serialization occurs before the request gets access to a thread. So,
there is no way to avoid it other than to not use the Session intrinsics.
If you use something other than ASP sessions for your Session control (e.g.
some of the Session solutions that use a DB backend) it becomes the
responsibility of those solutions to control the Session consistency.

Pat

"PJ" <pj***@hotmail.com> wrote in message
news:uq**************@TK2MSFTNGP11.phx.gbl...

I posted a few days ago concerning requests being blocked from a main window after a popup window had initiated a file download. Apparently this has to do with the fact that asp.net or iis serialize all requests from the same
session. Further requests from the same session are being queued until the download is complete. So, is there any way to override this? Is there
anyway to tell asp.net to not serialize same session requests? Is there any way to tell asp.net to ignore session for a specific
request...httphander(module) or otherwise? Why is this the case anyhow?
Thread safety for session?

TIA~ PJ

Thanks Pat. You're not off the hook quite yet though. Couple of
questions...the first to throw out the gauntlet, the second for straight up
practicality.

Latter first...
Can we not override configuration on the folder if not the file level? I
attempted to put a configuration file at the folder level to disable Session
state via the <pages> element, but I just received errors. Can you point me
to a resource that explains how to do this? If I can pass a request key to
my sessionless popup, then said popup could grab necessary state information
from the web cache and main window and popup could continue on their merry
way, w/out blocking each others requests.

Gauntlet...
Was the serialization of session requests designed to protect framework
programmers or framework users from having to write thread safe code to
session?

TIA~ PJ

Thanks Pat. You're not off the hook quite yet though. Couple of
questions...the first to throw out the gauntlet, the second for straight up
practicality.

Latter first...
Can we not override configuration on the folder if not the file level? I
attempted to put a configuration file at the folder level to disable Session
state via the <pages> element, but I just received errors. Can you point me
to a resource that explains how to do this? If I can pass a request key to
my sessionless popup, then said popup could grab necessary state information
from the web cache and main window and popup could continue on their merry
way, w/out blocking each others requests.

Gauntlet...
Was the serialization of session requests designed to protect framework
programmers or framework users from having to write thread safe code to
session?

TIA~ PJ

If the popup is not participating in the Session, then I do not believe that
it will be able to get the data. You should be able to override at the
folder level, but the Session data won't be available there for lookup (it
is a scope thing). Designing Microsoft ASP.Net Applications (MS-Press) has
a bit to say about it but I'm not sure that it would help you much in this
case. Next time you're at Barnes and Nobles check out pages 100->105.

Actually, the Serialization goes back to IIS3. So, it is more a matter of
..Net persisting previous behaviors. On the trivia side, 'legacy' ASP
threads are STA threads b/c the majority of COM programmers used VB
(minimize the marshalling). STA objects are protected from multiple thread
access by COM. So, the Session serialization was not for threading. It was
really more to ease the migration of fat client applications to the web.
Fat clients, as a general rule, maintained a significant amount of 'state'
information. So, having an Intrinsic (MTA) object that could store session
information for multiple users was a big help.

ASP.Net improves the Session info significantly (lower overhead, more
flexible in object storage), but some of the 'rules' remained. This is one.

Pat

"PJ" <pj*********@hotmail.com> wrote in message
news:OZ**************@TK2MSFTNGP09.phx.gbl...

Thanks Pat. You're not off the hook quite yet though. Couple of
questions...the first to throw out the gauntlet, the second for straight up practicality.

Latter first...
Can we not override configuration on the folder if not the file level? I
attempted to put a configuration file at the folder level to disable Session state via the <pages> element, but I just received errors. Can you point me to a resource that explains how to do this? If I can pass a request key to my sessionless popup, then said popup could grab necessary state information from the web cache and main window and popup could continue on their merry
way, w/out blocking each others requests.

Gauntlet...
Was the serialization of session requests designed to protect framework
programmers or framework users from having to write thread safe code to
session?

TIA~ PJ

thanks Pat....good explanation.

Correct me if I'm wong, but the sessionless popup will still have access to
the web cache, correct? If so, I can store my necessary state information
in the web cache and the popup will access it via a key given to it in a
request variable. The popup would immediately remove the item from cache as
well.

The override works as expected...
<configuration>
<location path="popup">
<system.web>
<pages buffer="false" enableSessionState="false"
enableViewState="false"
enableViewStateMac="false" autoEventWireup="false" />
</system.web>

"Pat [MSFT]" <pa******@online.microsoft.com> wrote in message
news:O$**************@TK2MSFTNGP11.phx.gbl...

If the popup is not participating in the Session, then I do not believe that it will be able to get the data. You should be able to override at the
folder level, but the Session data won't be available there for lookup (it
is a scope thing). Designing Microsoft ASP.Net Applications (MS-Press) has a bit to say about it but I'm not sure that it would help you much in this
case. Next time you're at Barnes and Nobles check out pages 100->105.

Actually, the Serialization goes back to IIS3. So, it is more a matter of
.Net persisting previous behaviors. On the trivia side, 'legacy' ASP
threads are STA threads b/c the majority of COM programmers used VB
(minimize the marshalling). STA objects are protected from multiple thread access by COM. So, the Session serialization was not for threading. It was really more to ease the migration of fat client applications to the web.
Fat clients, as a general rule, maintained a significant amount of 'state'
information. So, having an Intrinsic (MTA) object that could store session information for multiple users was a big help.

ASP.Net improves the Session info significantly (lower overhead, more
flexible in object storage), but some of the 'rules' remained. This is one.
Pat

"PJ" <pj*********@hotmail.com> wrote in message
news:OZ**************@TK2MSFTNGP09.phx.gbl...

Thanks Pat. You're not off the hook quite yet though. Couple of
questions...the first to throw out the gauntlet, the second for straight up

practicality.

Latter first...
Can we not override configuration on the folder if not the file level? I attempted to put a configuration file at the folder level to disable

Session

state via the <pages> element, but I just received errors. Can you point me

to a resource that explains how to do this? If I can pass a request key

to

my sessionless popup, then said popup could grab necessary state

information

from the web cache and main window and popup could continue on their

merry way, w/out blocking each others requests.

Gauntlet...
Was the serialization of session requests designed to protect framework
programmers or framework users from having to write thread safe code to
session?

TIA~ PJ