[thelist] Friday Freebie

[Scott Dexter]

dunno about you, but this week went by pretty fast here, and a good dose of
biscuits and gravy didn't hurt....

<tip type="Session object notes" author="Scott Dexter"
email="sgd at thinksafely.org">
* The Session_OnStart in the global.asa subroutine is reliable

* The Session_OnEnd is NOT. --don't use it (its not fixed in IIS5)

* When using Session.Abandon, existing Session values are available until
the page finishes processing. In other words, You can have Session.Abandon
and still use Session values on the same page, just not after it

* Placing an apartment threaded object into a Session variable is a **BAD**
thing. It reduces IIS to a single thread, and will seriously hose your
performance. The current set of ADO objects are of this type. So is the
MS-provided Dictionary object. Check and make sure the components you load
into Session variables are 'free' or 'both' threaded

* If you're placing values from a recordset into Session variables, cast
them to ensure that they aren't passed by reference --which would be a
pointer to the recordset's value, such that when you close the recordset
your Session variable is blown away. Casting causes it to be passed by
value, which is safe: Session("userid") = CStr(oRS("userid"))

* Session objects are stored on the web server, not in cookies. The only
cookie that is passed back and forth with the browser is the Session ID
(SESSID), a really, really long randomly generated string. MS SiteServer
passes an ID value in addition to the SESSID

* Beware of large structures/amounts of data in Session variables. Remember
that you are taking up server memory with Session objects, and they don't go
away quickly; I don't want you eating up all your server's memory with
umpteen million Session objects. Look into storing back to a db instead
</tip>

I'm gonna shoot for a non-ASP FF next week ....

(stop snickering)
sgd
--
work: http://www.ti3.com/
non: http://thinksafely.org/