Temporary Use of Session Object

Discussion in 'ASP General' started by jamie.jamazon@googlemail.com, Oct 29, 2007.

  1. Guest

    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, 2007
    #1
    1. Advertising

  2. Evertjan. Guest

    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.

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Oct 29, 2007
    #2
    1. Advertising

  3. Guest

    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.
     
    , Oct 29, 2007
    #3
  4. 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


    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.
    --
    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"
     
    Bob Barrows [MVP], Oct 29, 2007
    #4
  5. Evertjan. Guest

    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)
     
    Evertjan., Oct 29, 2007
    #5
  6. "" 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
     
    Anthony Jones, Oct 29, 2007
    #6
  7. Guest

    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, 2007
    #7
  8. Guest


    > Did you mean the jscript vs vbscript language barrier?


    heh, yeh
     
    , Oct 29, 2007
    #8
  9. wrote:
    > 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


    --
    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"
     
    Bob Barrows [MVP], Oct 29, 2007
    #9
  10. Guest

    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, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. momo898
    Replies:
    2
    Views:
    505
    bruce barker \(sqlwork.com\)
    Oct 12, 2006
  2. archana
    Replies:
    1
    Views:
    399
    Alexey Smirnov
    Feb 27, 2007
  3. Jess
    Replies:
    10
    Views:
    510
    James Kanze
    May 18, 2007
  4. Replies:
    7
    Views:
    3,265
    James Kanze
    Feb 12, 2008
  5. kublai khan
    Replies:
    1
    Views:
    100
Loading...

Share This Page