Temporary Use of Session Object

[jamie.jamazon]

I'm currently developing a small MVC framework using classic ASP
(don't ask me why!) At it's core it calls the controller script which
does the heavy logic and builds disconnected recordsets of the
required data then transparently "includes" a page template asp script
using a Server.Execute.

Because of the limitations of Server.Execute and Server.Transfer the
data generated by the controller needs to be persisted past the
Server.Execute call by placing it into the Session Object. At the end
of each request everything placed into the Session object is removed
and the session is abandoned. Session.Timeout is also set to 1 at the
start of each request. I don't want or require anything to persist
past each request (contrary to the traditional role of session
variables) so this isn't a problem. I have a more robust database
session management system for this.

My question is, am I going to run into any scalability issues while
using the Session object in this way? I've heard whispers of thread
locking and heap fragmentation linked to storing large amounts of data
in Session, but I get the feeling this might only be so much of a
problem if the data is being persisted for the default 20 mins or
longer with each request.

Please feel free to shoot me down in flames here... or suggest an
alternative approach to persisting data through a Server.Execute/
Transfer

[Evertjan.]

wrote on 29 okt 2007 in microsoft.public.inetserver.asp.general:

Sorry i think you appear to have misunderstood my question. I'm not
sure if perhaps this is a language barrier thing, but i get the
distinct impression that you belive i am trying to suggest that
Classic ASP is not a serious development platform, This is not the
case

OK.

Did you mean the jscript vs vbscript language barrier?

;-)

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[jamie.jamazon]

Thanks for the heads up on the batch file. I was planning on placing
the disconnected recordsets into the Session object and the thread-
binding is what was concerning me. I don't come from an ASP/VBScript
background.. or a Microsoft one at all for that matter so it's helpful
to get an insight into stuff like this. It's often difficult to find
advice on Classic ASP techniques and best practices as the community
isn't as large as it could or should be.

My application uses disconnected recordsets simply as arrays of data
with which to generate html. I could generate dictionary objects from
the recordsets but i believe these are apartment threaded also.

I agree about the Timeout and Abandon settings, these are both
unnecessary. I was thinking in terms of belt and braces garbage
collection, but i can see now that this was in error

[=?Utf-8?B?QW50aG9ueSBKb25lcw==?=]

"ja***********@googlemail.com" wrote:

I'm currently developing a small MVC framework using classic ASP
(don't ask me why!) At it's core it calls the controller script which
does the heavy logic and builds disconnected recordsets of the
required data then transparently "includes" a page template asp script
using a Server.Execute.

Because of the limitations of Server.Execute and Server.Transfer the
data generated by the controller needs to be persisted past the
Server.Execute call by placing it into the Session Object. At the end
of each request everything placed into the Session object is removed
and the session is abandoned. Session.Timeout is also set to 1 at the
start of each request. I don't want or require anything to persist
past each request (contrary to the traditional role of session
variables) so this isn't a problem. I have a more robust database
session management system for this.

My question is, am I going to run into any scalability issues while
using the Session object in this way? I've heard whispers of thread
locking and heap fragmentation linked to storing large amounts of data
in Session, but I get the feeling this might only be so much of a
problem if the data is being persisted for the default 20 mins or
longer with each request.

Please feel free to shoot me down in flames here... or suggest an
alternative approach to persisting data through a Server.Execute/
Transfer

To clear the contents of a session use Session.Contents.RemoveAll.

This is preferable than having the session timeout quickly (or deliberately
abandoning in the session with the abandon method). You should set the
session timeout to a reasonable period that your users will be running a
browser session that will be visiting your site.

Using session object to store variables isn't going to fragment memory
anymore than storing variables in any other way.

--
Anthony Jones - MVP ASP/ASP.NET

[jamie.jamazon]

Did you mean the jscript vs vbscript language barrier?

heh, yeh

[jamie.jamazon]

I'd like to say a big thankyou for the advice about using free-
threaded xml docs to store data. so simple yet so effective. i don't
know why i didn't think of this myself.