468,505 Members | 1,548 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,505 developers. It's quick & easy.

Temporary Use of Session Object

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

Oct 29 '07 #1
5 1844
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)
Oct 29 '07 #2
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

Oct 29 '07 #3
"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

Oct 29 '07 #4
Did you mean the jscript vs vbscript language barrier?
heh, yeh

Oct 29 '07 #5
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.

Oct 29 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Philippe Meunier | last post: by
2 posts views Thread by David Parker | last post: by
2 posts views Thread by stefan.albert | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.