Problem with Sessions / Cookies
Problem with Sessions / Cookies
am 28.12.2007 15:11:00 von 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
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
am 29.12.2007 15:52:33 von Anthony Jones
"Simon Dean" 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.
>
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
Re: Problem with Sessions / Cookies
am 01.01.2008 22:21:41 von Simon Dean
Anthony Jones wrote:
> "Simon Dean" 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.
>>
>
>
>
> 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.
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
am 02.01.2008 23:28:26 von Anthony Jones
"Simon Dean" wrote in message
news:5tvpc4F1fmctsU1@mid.individual.net...
> Anthony Jones wrote:
> > "Simon Dean" 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.
> >>
> >
> >
> >
> > 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
Re: Problem with Sessions / Cookies
am 03.01.2008 10:00:18 von Simon Dean
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
Re: Problem with Sessions / Cookies
am 03.01.2008 10:50:52 von Anthony Jones
"Simon Dean" wrote in message
news:5u3mchF1g18b6U1@mid.individual.net...
> 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
Re: Problem with Sessions / Cookies
am 03.01.2008 11:34:07 von Simon Dean
Anthony Jones wrote:
> "Simon Dean" wrote in message
> news:5u3mchF1g18b6U1@mid.individual.net...
>> 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.
Re: Problem with Sessions / Cookies
am 03.01.2008 13:04:44 von reb01501
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"
Re: Problem with Sessions / Cookies
am 03.01.2008 14:17:29 von Anthony Jones
"Bob Barrows [MVP]" wrote in message
news:uwLLUDgTIHA.4656@TK2MSFTNGP03.phx.gbl...
> 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
Re: Problem with Sessions / Cookies
am 03.01.2008 17:09:36 von reb01501
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.