Problem with Sessions / Cookies

Discussion in 'ASP General' started by Simon Dean, Dec 28, 2007.

  1. Simon Dean

    Simon Dean Guest

    Hi,

    I believe I have a website (I didn't do the original coding) which uses
    JavaScript/ASP to generate cookies.

    It's a shopping cart application called UCart I believe.

    The technologies involved are:

    ASP
    JavaScript
    IIS
    Microsoft Access

    Im transferring this to a new host but am finding a problem with
    Cookies. On the previous host, it was solved by them configuring the
    server to place the website into a "lower contention session pool".

    Has anyone heard of this, or can they offer any ideas as to how this
    might be effected programmatically, or what a suggested alternative
    might be.

    To be honest Im having trouble figuring this mess out and how its all
    called.

    Thanks
    Simon


    Here is a snippet of code.

    Im having trouble understanding the correlation between JavaScript and
    ASP and although the code appears to be within <SCRIPT
    LANGUAGE=JavaScript RUNAT=Server NAME="UC_CART"> tags,I gather that it
    using Sessions on the server through ASP.

    What's happening is that in the process, two Session Id's are being
    generated.

    // Each of these is an array. Each array index corresponds to a line item.
    // As such, each array should always be exactly the same length.
    this.AssertCartValid(colNames, "Cart Initialization: ");
    if (Session(this.Name) != null) {
    this.SC = Session(this.Name).SC;
    } else {
    this.SC = new Array(this.numCols);
    for (var i = 0; i < this.numCols; i++) this.SC = new Array();

    // Since the cart doesn't exist in session, check for cookie
    from previous session
    if (this.bStoreCookie){
    cookieName = this.GetCookieName();
    cookieStr = Request.Cookies(cookieName);
    if (cookieStr != null && String(cookieStr) != "undefined"
    && cookieStr != "")
    this.PopulateFromCookie(cookieStr);
    }
    // Create a reference in the Session, pass the whole object
    (methods are not copied)
    this.persist();
    }

    function SetCookie(){
    var cookieName = this.GetCookieName()
    var cookieStr = this.GetContentsSerial(this.cookieColDel,
    this.cookieRowDel)
    var cookieExp = GetCookieExp(this.cookieLifetime)
    Response.Cookies(cookieName) = cookieStr
    Response.Cookies(cookieName).expires = cookieExp
    }

    function UCpersist() {
    Session(this.Name) = this;
    if (this.bStoreCookie) this.SetCookie();
    }
     
    Simon Dean, Dec 28, 2007
    #1
    1. Advertising

  2. "Simon Dean" <> wrote in message
    news:...
    > Hi,
    >
    > I believe I have a website (I didn't do the original coding) which uses
    > JavaScript/ASP to generate cookies.
    >
    > It's a shopping cart application called UCart I believe.
    >
    > The technologies involved are:
    >
    > ASP
    > JavaScript
    > IIS
    > Microsoft Access
    >
    > Im transferring this to a new host but am finding a problem with
    > Cookies. On the previous host, it was solved by them configuring the
    > server to place the website into a "lower contention session pool".
    >
    > Has anyone heard of this, or can they offer any ideas as to how this
    > might be effected programmatically, or what a suggested alternative
    > might be.
    >
    > To be honest Im having trouble figuring this mess out and how its all
    > called.
    >
    > Thanks
    > Simon
    >
    >
    > Here is a snippet of code.
    >


    <snip />

    The problem is here:-

    > if (Session(this.Name) != null) {
    > this.SC = Session(this.Name).SC;
    > } else {
    > this.SC = new Array(this.numCols);


    and here:-

    >function UCpersist() {
    > Session(this.Name) = this;
    > if (this.bStoreCookie) this.SetCookie();
    >}


    The code is storing an object in the Session. When this happens an
    affiliation is created between the current thread and the session. ASP
    Requests for this session must now always be run on the affiliated thread.
    This creates 'contention' when two or more requests arrive which require the
    same thread. Despite there being other worker threads available and CPU
    capacity only one of requests can be processed and the others have to queue.
    This hurts scalability and is generally discouraged.

    You can help to reduce this (IMO poor design choice) by increasing the
    AspProcessorThreadMax metabase property (default is 25). This property
    defines the maximum size of the worker thread pool. Increasing this can
    help spread the sessions across multiple threads thereby decreasing the
    thread contention that results from session affiliation.

    The downside is that potentially you end up with too many threads trying to
    execute at once resulting in the cost of extra context switching. The
    impact of the extra switching is probably a lot less than leaving requests
    queued up that might otherwise begin processing.


    --
    Anthony Jones - MVP ASP/ASP.NET
     
    Anthony Jones, Dec 29, 2007
    #2
    1. Advertising

  3. "Simon Dean" <> wrote in message
    news:...
    > Anthony Jones wrote:
    > > "Simon Dean" <> wrote in message
    > > news:...
    > >> Hi,
    > >>
    > >> I believe I have a website (I didn't do the original coding) which uses
    > >> JavaScript/ASP to generate cookies.
    > >>
    > >> It's a shopping cart application called UCart I believe.
    > >>
    > >> The technologies involved are:
    > >>
    > >> ASP
    > >> JavaScript
    > >> IIS
    > >> Microsoft Access
    > >>
    > >> Im transferring this to a new host but am finding a problem with
    > >> Cookies. On the previous host, it was solved by them configuring the
    > >> server to place the website into a "lower contention session pool".
    > >>
    > >> Has anyone heard of this, or can they offer any ideas as to how this
    > >> might be effected programmatically, or what a suggested alternative
    > >> might be.
    > >>
    > >> To be honest Im having trouble figuring this mess out and how its all
    > >> called.
    > >>
    > >> Thanks
    > >> Simon
    > >>
    > >>
    > >> Here is a snippet of code.
    > >>

    > >
    > > <snip />
    > >
    > > The problem is here:-
    > >
    > >> if (Session(this.Name) != null) {
    > >> this.SC = Session(this.Name).SC;
    > >> } else {
    > >> this.SC = new Array(this.numCols);

    > >
    > > and here:-
    > >
    > >> function UCpersist() {
    > >> Session(this.Name) = this;
    > >> if (this.bStoreCookie) this.SetCookie();
    > >> }

    > >
    > > The code is storing an object in the Session. When this happens an
    > > affiliation is created between the current thread and the session. ASP
    > > Requests for this session must now always be run on the affiliated

    thread.
    > > This creates 'contention' when two or more requests arrive which require

    the
    > > same thread. Despite there being other worker threads available and CPU
    > > capacity only one of requests can be processed and the others have to

    queue.
    > > This hurts scalability and is generally discouraged.
    > >
    > > You can help to reduce this (IMO poor design choice) by increasing the
    > > AspProcessorThreadMax metabase property (default is 25). This property
    > > defines the maximum size of the worker thread pool. Increasing this can
    > > help spread the sessions across multiple threads thereby decreasing the
    > > thread contention that results from session affiliation.
    > >
    > > The downside is that potentially you end up with too many threads trying

    to
    > > execute at once resulting in the cost of extra context switching. The
    > > impact of the extra switching is probably a lot less than leaving

    requests
    > > queued up that might otherwise begin processing.
    > >
    > >

    >
    > Thanks for the reply Anthony.
    >
    > Im not too familiar with ASP etc, but let me see if I get this straight.
    >
    > I presume you access the same session from different threads providing
    > one of the threads has finished.


    Normally, yes, when only simple primitive data like numbers, dates and
    strings (or arrays of such) are stored in the session object. In that case
    iwhich of the ASP worker threads processes a request will not matter, any
    will do.

    However when a session object has had a single threaded object stored in it,
    it becomes affiliated with the worker thread and can only be processed by
    that specific thread.

    >
    > Im confused therefore, unless two Session requests are running
    > simultaneously.
    >


    That can't happen. The session object itself is single threaded and
    therefore cannot be used by two threads simultaneously. Hence when there
    are multiple outstanding requests from a single browser session for ASP
    resources only one such request will be processed, the others will queue
    (this is rare).


    > If we can't make changes to the servers, what's the solution? Is it a
    > case of ripping through the code and basically restructuring all the
    > Session calls to be more sequential?
    >


    It would be case of changing the code so that it no longer places objects in
    the session object.

    --
    Anthony Jones - MVP ASP/ASP.NET
     
    Anthony Jones, Jan 2, 2008
    #3
  4. Simon Dean

    Simon Dean Guest

    Anthony Jones wrote:
    > "Simon Dean" <> wrote in message


    >> If we can't make changes to the servers, what's the solution? Is it a
    >> case of ripping through the code and basically restructuring all the
    >> Session calls to be more sequential?
    >>

    >
    > It would be case of changing the code so that it no longer places objects in
    > the session object.
    >


    Or in other words, in this situation, to use the database to store order
    information, and convert the Session to merely process cookies and
    provide a link between browser, website, and database.

    Cheers
    Simon
     
    Simon Dean, Jan 3, 2008
    #4
  5. "Simon Dean" <> wrote in message
    news:...
    > Anthony Jones wrote:
    > > "Simon Dean" <> wrote in message

    >
    > >> If we can't make changes to the servers, what's the solution? Is it a
    > >> case of ripping through the code and basically restructuring all the
    > >> Session calls to be more sequential?
    > >>

    > >
    > > It would be case of changing the code so that it no longer places

    objects in
    > > the session object.
    > >

    >
    > Or in other words, in this situation, to use the database to store order
    > information, and convert the Session to merely process cookies and
    > provide a link between browser, website, and database.
    >


    Yes thats an option and may be necessary in some circumstances.

    However another solution would be to get hold of some Javascript JSON
    serialisation code. This could be used to take the object that is currently
    being assigned into the session and serialise it to a JSON string. The
    string could be deserialised back to an object when fetched.


    See:-

    http://www.json.org/js.html


    --
    Anthony Jones - MVP ASP/ASP.NET
     
    Anthony Jones, Jan 3, 2008
    #5
  6. Simon Dean

    Simon Dean Guest

    Anthony Jones wrote:
    > "Simon Dean" <> wrote in message
    > news:...
    >> Anthony Jones wrote:
    >>> "Simon Dean" <> wrote in message
    >>>> If we can't make changes to the servers, what's the solution? Is it a
    >>>> case of ripping through the code and basically restructuring all the
    >>>> Session calls to be more sequential?
    >>>>
    >>> It would be case of changing the code so that it no longer places

    > objects in
    >>> the session object.
    >>>

    >> Or in other words, in this situation, to use the database to store order
    >> information, and convert the Session to merely process cookies and
    >> provide a link between browser, website, and database.
    >>

    >
    > Yes thats an option and may be necessary in some circumstances.
    >
    > However another solution would be to get hold of some Javascript JSON
    > serialisation code. This could be used to take the object that is currently
    > being assigned into the session and serialise it to a JSON string. The
    > string could be deserialised back to an object when fetched.
    >
    >
    > See:-
    >
    > http://www.json.org/js.html
    >
    >


    Thank you very much Anthony, you have been extremely helpful and your
    advice is much appreciated.
     
    Simon Dean, Jan 3, 2008
    #6
  7. Simon Dean wrote:
    > Anthony Jones wrote:
    >> "Simon Dean" <> wrote in message

    >
    >>> If we can't make changes to the servers, what's the solution? Is it
    >>> a case of ripping through the code and basically restructuring all the
    >>> Session calls to be more sequential?
    >>>

    >>
    >> It would be case of changing the code so that it no longer places
    >> objects in the session object.
    >>

    >
    > Or in other words, in this situation, to use the database to store
    > order information, and convert the Session to merely process cookies
    > and provide a link between browser, website, and database.
    >

    Another alternative to JSON is to use a free-threaded XML DOM Document which
    will at least avoid the serialization/deserialization steps required by the
    JSON approach. The free-threaded version of the object can be stored in
    session/application without causing the thread-binding issues caused by your
    current approach.

    Frankly, never having used JSON, I have no first-hand knowledge of the
    benefits gained by selecting either approach.

    --
    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], Jan 3, 2008
    #7
  8. "Bob Barrows [MVP]" <> wrote in message
    news:...
    > Simon Dean wrote:
    > > Anthony Jones wrote:
    > >> "Simon Dean" <> wrote in message

    > >
    > >>> If we can't make changes to the servers, what's the solution? Is it
    > >>> a case of ripping through the code and basically restructuring all the
    > >>> Session calls to be more sequential?
    > >>>
    > >>
    > >> It would be case of changing the code so that it no longer places
    > >> objects in the session object.
    > >>

    > >
    > > Or in other words, in this situation, to use the database to store
    > > order information, and convert the Session to merely process cookies
    > > and provide a link between browser, website, and database.
    > >

    > Another alternative to JSON is to use a free-threaded XML DOM Document

    which
    > will at least avoid the serialization/deserialization steps required by

    the
    > JSON approach. The free-threaded version of the object can be stored in
    > session/application without causing the thread-binding issues caused by

    your
    > current approach.
    >
    > Frankly, never having used JSON, I have no first-hand knowledge of the
    > benefits gained by selecting either approach.
    >


    The JSON approach has the benefit that once deserialised the object can be
    used by the remaining code as is. Whereas with XML (or using a DB) all code
    in the app will be affected and will need some modification.


    --
    Anthony Jones - MVP ASP/ASP.NET
     
    Anthony Jones, Jan 3, 2008
    #8
  9. Anthony Jones wrote:
    >> Another alternative to JSON is to use a free-threaded XML DOM
    >> Document which will at least avoid the serialization/deserialization
    >> steps required by the JSON approach. The free-threaded version of
    >> the object can be stored in session/application without causing the
    >> thread-binding issues caused by your current approach.
    >>
    >> Frankly, never having used JSON, I have no first-hand knowledge of
    >> the benefits gained by selecting either approach.
    >>

    >
    > The JSON approach has the benefit that once deserialised the object
    > can be used by the remaining code as is. Whereas with XML (or using
    > a DB) all code in the app will be affected and will need some
    > modification.
    >
    >

    Noted

    --
    Microsoft MVP -- ASP/ASP.NET
    Please reply to the newsgroup. The email account listed in my From
    header is my spam trap, so I don't check it very often. You will get a
    quicker response by posting to the newsgroup.
     
    Bob Barrows [MVP], Jan 3, 2008
    #9
    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. Ken Cox [Microsoft MVP]

    Re: Relationship between IIS Sessions and ASP.NET Sessions?

    Ken Cox [Microsoft MVP], Aug 8, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    5,369
    Luther Miller
    Aug 8, 2003
  2. Thomas Scheiderich

    Cookies, sessions and timeouts

    Thomas Scheiderich, Jun 23, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    454
    Thomas Scheiderich
    Jun 24, 2004
  3. _Who
    Replies:
    7
    Views:
    2,679
  4. scottymo
    Replies:
    3
    Views:
    706
    Dominick Baier
    Sep 30, 2006
  5. Bookham Measures

    Moving from ASP Sessions to Database Sessions

    Bookham Measures, Jul 23, 2007, in forum: ASP General
    Replies:
    19
    Views:
    569
    Bookham Measures
    Aug 23, 2007
Loading...

Share This Page