Problem with Sessions / Cookies

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[i] = 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();
}

re: Problem with Sessions / Cookies

"Simon Dean" <sjdean@simtext.plus.comwrote in message
news:5tkeb9F1dm9j3U1@mid.individual.net...<snip />

The problem is here:-
and here:-
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

re: Problem with Sessions / Cookies

Anthony Jones wrote: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.

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

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?

Cheers
Simon

re: Problem with Sessions / Cookies

"Simon Dean" <sjdean@gmail.comwrote in message
news:5tvpc4F1fmctsU1@mid.individual.net...thread.thequeue.torequestsNormally, 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.
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).

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