|
it
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Temporary Use of Session Object
(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 wrote on 29 okt 2007 in microsoft.public.inetserver.asp.general:
> I'm currently developing a small MVC framework using classic ASP I think you are a bit insulting.> (don't ask me why!) 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. Show quote > At it's core it calls the controller script which Programming is all about testing. > 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 Why 20 minutes?> 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. 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 There seems to be no reason to kill the session object for this.> alternative approach to persisting data through a Server.Execute/ > Transfer -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress) 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 andanalysable 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 toavoid 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 ofpersistence. 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. wrote on 29 okt 2007 in microsoft.public.inetserver.asp.general:
> Sorry i think you appear to have misunderstood my question. I'm not OK.> 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 Did you mean the jscript vs vbscript language barrier? ;-) -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress) jamie.jama***@googlemail.com wrote:
Show quote > I'm currently developing a small MVC framework using classic ASP The only reason you would run into threading issues is if you stored > (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 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. -- Microsoft MVP - ASP/ASP.NET Please reply to the newsgroup. This email account is my spam trap so I don't check it very often. If you must reply off-line, then remove the "NO SPAM" 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.jama***@googlemail.com wrote:
> Thanks for the heads up on the batch file. I was planning on placing Right. Arrays and free-threaded xml documents are certainly valid > 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. > alternatives. Some further info can be seen here: http://classicasp.aspfaq.com/components/should-i-store-objects-in-session/application-scope.html -- Microsoft MVP - ASP/ASP.NET Please reply to the newsgroup. This email account is my spam trap so I don't check it very often. If you must reply off-line, then remove the "NO SPAM" 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. Show quote
"jamie.jama***@googlemail.com" wrote: To clear the contents of a session use Session.Contents.RemoveAll.> 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 > 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  
Other interesting topics
|
|||||||||||||||||||||||
