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;").
--
Mark Schupp
Head of Development
Integrity eLearning
www.ielearning.com
"Rob Meade" <robb.meade@NO-SPAM.kingswoodweb.net> wrote in message
news:fv8ob.250$4D5.2749587@news-text.cableinet.net...[color=blue]
> "Mark Schupp" wrote...
>[color=green]
> > You might want to check and see if "session" cookies are allowed.[/color]
>
> Yep - we are already using these in our applications and for our login[/color]
etc..[color=blue]
>[color=green]
> > Session cookies disappear when the browser is re-started.[/color]
>
> 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[/color]
to[color=blue]
> anything anymore on the server which dropped)
>[color=green]
> > The only thing you would keep in it would be an identifier for the[/color][/color]
user's[color=blue][color=green]
> > 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[/color]
> database.
>
> Ok, so I've just logged in, I have a session on server A, this is created[/color]
in[color=blue]
> 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[/color]
session("sessionid")[color=blue]
> 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[/color]
checking[color=blue]
> the datetime the session was created in the database? And if so,[/color]
presumably[color=blue]
> each time the database is checked (at the start of each new page loading)[/color]
I[color=blue]
> 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[/color]
my[color=blue]
> initial post, where it seems that the servers havent finished doing[/color]
whatever[color=blue]
> 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...
>[color=green]
> > Another approach is to put the session identifier in the URL for every[/color]
> link[color=green]
> > in the application (this is how "cookie munger" worked).[/color]
>
> 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[/color]
of[color=blue]
> the various levels of competance (for IT at least) out there...I'm not[/color]
sure[color=blue]
> that this would be an approach we could take.
>
> Thanks again for your reply.
>
> Regards
>
> Rob
>
>[/color]
