Problem with Sessions / Cookies

[Simon Dean]

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();
}

 

[Anthony Jones]

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]

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.

 

[Simon Dean]

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

 

[Anthony Jones]

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

 

[Simon Dean]

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.

 

[Bob Barrows [MVP]]

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.

 

[Anthony Jones]

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.

 

[Bob Barrows [MVP]]

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