Passing/Storing Sessions on Clustered Server?

[Rob Meade]

Hi all,

At work we have 2 servers in a cluster for our web apps.

One problem we have experienced (along with many others!) - is that if a
user is logged into one of the applications on server a for example and it
goes offline or fails their session is lost also - even though the
application becomes available on server b.

I have heard that it is possible to either exchange the sessions between
clustered servers or store them in a SQL Server database (probably
preferred) so that we could then restore them if such a failure should
occur.

Can anyone shed any light on this for me? Or give me some URL's to check out
and read.

Sorry this isn't a 100% pure IIS question - its obviously partly ASP also.

Thanks in advance for any help you can offer.

Regards

Robb

PS: Windows 2000 servers, SP3, Application Center 2000 SP1 (sp2 about to be
applied), SQL Server 2000 SP2 (sp3 about to be applied).

 

[Mark Schupp]

You will need to "roll your own" sessions by putting the session data into a
database and using a cookie, hidden form field, or URL parameter to identify
the session. There are a number of articles out there on this. Also see
www.aspfaq.com. There are also a number of 3rd-party "session" objects that
support this behavior as well.

As I understand it, .NET has most of this built-in.

 

[Rob Meade]

...

You will need to "roll your own" sessions by putting the session data into a
database and using a cookie, hidden form field, or URL parameter to identify
the session. There are a number of articles out there on this. Also see
www.aspfaq.com. There are also a number of 3rd-party "session" objects that
support this behavior as well.
As I understand it, .NET has most of this built-in.

Hi Mark,

Thanks for your reply, my appologies for the delay with mine.

Just trying to think about the database/cookie/form field thing above...not
quite sure how this would work (in English let alone code)...

We have found that when one of our 2 clustered servers goes down, when the
user thats on a page on the failed server clicks to move on, submits a form,
refreshes or whatever, they simply get a blank page, as a result I'm not
sure that the above would work? There is obviously a small time delay in the
sychronization between the two servers when ones goes down..and I guess if
you're the lucky user that actions something at this point if it hasnt
sychnonized on the other server then you're stuffed...

Cookies are probably a no go...primarily because I work for the NHS
(National Health Service) in the UK and they do not like them being used,
also, whilst many of our applications cater for our own organisation within
the NHS, a lot of them are for a wider audience, and this is then were all
the different O/S's, browsers, browser settings and so forth start to eat
away at our applications.

The form field option could well work, as most of the applications have form
content on each of the pages anyway...but again I'm not sure about the above
with regards to the 'white page' etc...

Many thanks again for the reply, I will forward the information on to my
colleagues and hopefully we'll be able to get something to work - and soon!

Regards

Rob

 

[Mark Schupp]

You might want to check and see if "session" cookies are allowed. That is
what supports ASP sessions. A session cookie is an in-memory cookie (never
written to disk). Session cookies disappear when the browser is re-started.
The only thing you would keep in it would be an identifier for the user's
current logged on session (not an identifier for the user him(her)self).
That identifier would allow you to look up other session data in a database.

Another approach is to put the session identifier in the URL for every link
in the application (this is how "cookie munger" worked).

 

[Rob Meade]

...

You might want to check and see if "session" cookies are allowed.

Yep - we are already using these in our applications and for our login etc..

Session cookies disappear when the browser is re-started.

If the server drops, but the client still has the web page open - does the
session still exist (I appreciate at this stage that it would not relate to
anything anymore on the server which dropped)

The only thing you would keep in it would be an identifier for the user's
current logged on session (not an identifier for the user him(her)self).
That identifier would allow you to look up other session data in a

database.

Ok, so I've just logged in, I have a session on server A, this is created in
a database and its ID for example returned to me and saved in a session
variable.

If the server drops after a page has loaded, when I click on a link the
first thing the page I'm going to has to do is check my session("sessionid")
or something against the database.

If I'm not creating sessions on the other server (server b) how do I still
have users time out after 20 minutes for example? Would this be by checking
the datetime the session was created in the database? And if so, presumably
each time the database is checked (at the start of each new page loading) I
should be updating this datetime if I havent exceed the 20 minutes etc?

The only problem I can still see is the white screen that I mentioned in my
initial post, where it seems that the servers havent finished doing whatever
it is they do when one fails. If I only get a white page, ie no ASP is
processed, I still wont be able to return the session info....hmmm...

Another approach is to put the session identifier in the URL for every link
in the application (this is how "cookie munger" worked).

Hmm...that would require a hell of a lot of rewriting on the older
applications, and we often send URL's to various NHS professionals across
our patch - we normally try to keep this as 'simple' as possible because of
the various levels of competance (for IT at least) out there...I'm not sure
that this would be an approach we could take.

Thanks again for your reply.

Regards

Rob

 

[Mark Schupp]

You will not be able to use the ASP session id for the database key because
session ids are not unique between servers. What you need to do is create
your own session cookie (set a cookie with no expiration date) to contain a
key that you generate to identify the session in your database.

You will need to keep track of the last access time in your session table to
allow for session timeout. Check and update the time on each page access
when you load the session data (or when you update it on page exit). You may
also want a cleanup task to run periodically and delete old sessions from
the database.

The URL approach for passing the session id is what you would need if you
are not allowed to use any cookies at all. It is a lot more difficult
because you have to add it to every URL. Cookie Munger was an ISAPI filter
that would automatically convert session cookies to ids on the URL. It had
some serious drawbacks however. One was performance, it had to scan all
output HTML for links. Another was that it would not recognize URLs set in
script code (as in "document.location= aURL;").

 

[Rob Meade]

...

You will not be able to use the ASP session id for the database key because
session ids are not unique between servers.

I had guessed that would be the case...can we not use SQL unique identifier
instead?

What you need to do is create your own session cookie (set a cookie with

no expiration date) to contain a

key that you generate to identify the session in your database.

So a normal localised cookie on the users PC etc?

You will need to keep track of the last access time in your session table to
allow for session timeout. Check and update the time on each page access
when you load the session data (or when you update it on page exit). You may
also want a cleanup task to run periodically and delete old sessions from
the database.

Gotcha so far

The URL approach for passing the session id is what you would need if you
are not allowed to use any cookies at all. It is a lot more difficult
because you have to add it to every URL.

Yeah, I dont think the rest of our team would be too keen on that one

Cookie Munger was an ISAPI filter that would automatically convert session

cookies to ids on the URL. It had

some serious drawbacks however. One was performance, it had to scan all
output HTML for links. Another was that it would not recognize URLs set in
script code (as in "document.location= aURL;").

Deffo no go for us then as we do have a mixture of ASP and some client side
Javascript on various pages...

With regards to hitting the database continuously for the session stuff,
isn't that going to have a bit of a knock-on effect on performance? I
myself have developed one application that is used 24/7 by NHS staff who
update emergency admissions etc, they do this at the moment once every hour,
it only has about 3 pages in total which bounce back and forth to the
database etc, but multiply this by the number of locations/users etc, thats
quite a few hits to the server for the session info...

I'm still concerned about the white screen event though...I guess until we
try and test this approach we wont know...I'll not be around in the office
to test this for another week due to a .net training course, plus I'm not
sure if our development server is clustered also (probably not) - so I'll
have to speak to someone about that - it might mean that we can only test
this on a live cluster....

Thanks again for your help.

Regards

Rob