Concurrent Requests from Same Session

[PJ]

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

[Pat [MSFT]]

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" <pjwal@hotmail.com> wrote in message
news:uqt0Tg8VDHA.2032@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
>
>

[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

[Pat [MSFT]]

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" <pjwalNOSPAM@hotmail.com> wrote in message
news:OZG72eAWDHA.2344@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
>
>

[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]" <patfilot@online.microsoft.com> wrote in message
news:O$ivxvFWDHA.1180@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" <pjwalNOSPAM@hotmail.com> wrote in message
> news:OZG72eAWDHA.2344@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
> >
> >

>
>