Why is it a bad idea to put script objects in Session scope?

RE: Why is it a bad idea to put script objects in Session scope?

Blake — Fri, 19 Sep 2003 05:59:00 GMT

Ah yes, on a related note, back in the era of the NT4 Option Pack I wrote a lot of code that involved stashing Scripting.Dictionary objects in both session and application scope. These are normal COM objects and don't require a script engine, but fraught with their one problems. I forget now which version of the runtime changed the threading model they were registered with and broke everything for me.

RE: Why is it a bad idea to put script objects in Session scope?

Eric Lippert — Fri, 19 Sep 2003 08:38:00 GMT

Uh, yeah, that was my fault. Sorry about that. Everything you just read about ASP and threading is what I learned the day I marked the Scripting.Dictionary object as "Both" instead of "Apartment". I was young and foolish. There were a number of lessons we learned that day, some of which I may post about later.

re: Why is it a bad idea to put script objects in Session scope?

David Boccabella — Thu, 05 Feb 2004 12:55:00 GMT

I have been reading that the threading capabilities of the Dictionary object has been improved in IIS5 and thus it might be used as an Application variable.

I am trying to speed up performace by caching results from recordsset into HTML snippets so to reduce database hits

Dave

re: Why is it a bad idea to put script objects in Session scope?

Eric Lippert — Thu, 05 Feb 2004 17:55:00 GMT

You heard wrong then. No one has made a change to the Scripting.Dictionary object for many years now.

re: Why is it a bad idea to put script objects in Session scope?

Josh Painter — Fri, 07 May 2004 21:41:00 GMT

What about stashing a MSXML2.FreeThreadedDOMDocument.3.0 in a Session or Application variable? Is it safer to do this since it is free-threaded? If so, caching the XMLDOM object seems like a better alternative to parsing an XML page on each web page hit, correct? Thanks for your great posts!

re: Why is it a bad idea to put script objects in Session scope?

Eric Lippert — Fri, 07 May 2004 21:47:00 GMT

Free threaded objects are safe in session or application scope and do not introduce the performance penalty associated with marshaling.

Of course, they might introduce a performance penalty associated with excessive lock contention -- without actually trying it out, it's hard to say.

Basically what I'm saying is "that should work, but you should try it and see for yourself". Armchair performance analysis is generally worth what you pay for it.

re: Why is it a bad idea to put script objects in Session scope?

Bill Wilkinson — Tue, 29 Jun 2004 23:28:00 GMT

I have to ask...

You suggest that if you must use Session "variables" (boy, I hate that name--your "Session Scope" is much cleaner, thanks), you should use strings.

But consider: The overhead in VBS of doing
Session("whatever") = Join(someArray,"##")
and then later doing
someArray = Split( Session("whatever"), "##" )
*surely* is worse than the needed copy-in-copy-out for an array? Join may not be terribly "expensive", but Split certainly is. At least when you copy an array you already know how many elements are needed, what the size of each is, etc.

On top of that, if you are actually working with a 2D array (e.g., the result of ADODB.RecordSet.GetRows), the process of converting that to a string has to be long and painfully slow VBS string concatenation, no?

So the one exception I've always made to "don't store stuff in session scope" has always been 2D arrays. I just can't think of a better storage mechanism (well, except maybe moving them to JS arrays on the client, but that's another topic). [I won't argue if you want to tell me to go re-query the DB, but there *are* times where that's not very convenient and/or the performance may suck.]

Naturally, I *always* use a single "copy in" at the start of the ASP page and a single "copy out" at the end of the page. And then always work with VBS's local copy.

Commentary?