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:

I'm currently developing a small MVC framework using classic ASP

(don't ask me why!)

I think you are a bit insulting.

It is like asking a group of car lovers how to service a gearbox, and at
the same time telling them you think they are idiots not to use planes
exclusively for their transport.

Classic ASP, especially the jscript form, is far more chalenging to the
programmes mind to produce clean, consize, in depth understandable and
analysable code than the deaded .net form, you probably are referring to.

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?

Programming is all about testing.

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.

Why 20 minutes?

Try:

===== file1.asp =========
.....
session("transferrer") = myData
Server.transfer "file2.asp"
%>

===== file2.asp =========
<%
myData = session("transferrer")
Session.Contents.Remove("transferrer")
.....


Surely the persistence is in the order of a millisecond or so, not 20
minutes?

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

There seems to be no reason to kill the session object for this.

 

[jamie.jamazon]

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

Classic ASP, especially the jscript form, is far more chalenging to the

programmes mind to produce clean, consize, in depth understandable and
analysable code than the deaded .net form, you probably are referring
to.

Yes, i know. That's why i'm using it

Why 20 minutes?

20 minutes is the default session timeout, which i change to 1 to
avoid accidental persistence of large recordset objects between
requests.

Surely the persistence is in the order of a millisecond or so, not 20 minutes?

Indeed. This is what i am trying to achieve. The problem is not one of
persistence. The question i was asking was one of scalability in terms
of memory/thread usage and possible heap memory fragmentation which
can occur when using the session object in such a way.

I'm sorry that you have been insulted by my question, but that really
wasn't my intention. I feel my questions are valid. I merely am
curious to know if others have used such an approach and if there are
implications i should be aware of before heading along the wrong
route.

 

[Bob Barrows [MVP]]

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

The only reason you would run into threading issues is if you stored
single-threaded objects in Session or Application. ADO objects are, by
default, apartment-threaded, so they are not safe to store in Session or
Application. You mentioned disconnected recordsets ... are you putting the
recordsets themselves into Session? If so you do have a concern, since doing
so makes the Session object thread-bound, unless you make the registry
change to cause all ADO objects to be free-threaded. There's a batch file in
...\Program Files\Common Files\System\ADO called makfre15.bat that does this.
The problem with doing this is that you can no longer use a Jet backend
after you do it. So, if you are using Jet anywhere, you need to store the
data a different way. I usually create a free-threaded xml document
containing the data if I need to store it in session or application.

Immediately removing the objects from Session at the end of each request may
mitigate the problems, but i strongly feel you should rewrite things so you
store only scalar data or free-threaded objects in Session, which avoids the
problems in the first place.

I see no reason to abandon the session at the end of each request, or change
the timeout. Neither of these actions should have any effect on scalability.

 

[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?

;-)

 

[Anthony Jones]

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.

 

[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

 

[jamie.jamazon]

Did you mean the jscript vs vbscript language barrier?

heh, yeh

 

[Bob Barrows [MVP]]

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.

Right. Arrays and free-threaded xml documents are certainly valid
alternatives.

Some further info can be seen here:
http://classicasp.aspfaq.com/components/should-i-store-objects-in-session/application-scope.html

 

[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.