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