IIS ASP - Problem with Sessions / Cookies

Author

Problem with Sessions / Cookies

Simon Dean

2007-12-28, 1:26 pm

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

Anthony Jones

2007-12-29, 1:27 pm

"Simon Dean" <sjdean@simtext.plus.com> wrote in message
news:5tkeb9F1dm9j3U1@mid.individual.net...
> 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

Simon Dean

2008-01-01, 7:22 pm

Anthony Jones wrote:
> "Simon Dean" <sjdean@simtext.plus.com> wrote 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.
>
>

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

Anthony Jones

2008-01-02, 7:23 pm

"Simon Dean" <sjdean@gmail.com> wrote in message
news:5tvpc4F1fmctsU1@mid.individual.net...
> Anthony Jones wrote:
thread.[vbcol=seagreen]
the[vbcol=seagreen]
queue.[vbcol=seagreen]
to[vbcol=seagreen]
requests[vbcol=seagreen]
>
> 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

Simon Dean

2008-01-03, 7:30 am

Anthony Jones wrote:
> "Simon Dean" <sjdean@gmail.com> wrote in message

>
> 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

2008-01-03, 7:30 am

"Simon Dean" <sjdean@simtext.plus.com> wrote in message
news:5u3mchF1g18b6U1@mid.individual.net...
> Anthony Jones wrote:
>
objects in[vbcol=seagreen]
>
> 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

Simon Dean

2008-01-03, 7:30 am

Anthony Jones wrote:
> "Simon Dean" <sjdean@simtext.plus.com> wrote in message
> news:5u3mchF1g18b6U1@mid.individual.net...
> objects in
>
> 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]

2008-01-03, 7:30 am

Simon Dean wrote:
> Anthony Jones wrote:
>
>
> 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"

Anthony Jones

2008-01-03, 1:22 pm

"Bob Barrows [MVP]" <reb01501@NOyahoo.SPAMcom> wrote in message
news:uwLLUDgTIHA.4656@TK2MSFTNGP03.phx.gbl...
> Simon Dean 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.

--
Anthony Jones - MVP ASP/ASP.NET

Bob Barrows [MVP]

2008-01-03, 1:22 pm

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