Re: [REBOL] Re: Rebol/command, fastCGI, session id, frames, etc....
From: allenk:powerup:au at: 24-Jun-2001 15:46
----- Original Message -----
From: "Graham Chiu" <[gchiu--compkarori--co--nz]>
To: "Allen Kamp" <[allenk--powerup--com--au]>
Sent: Sunday, June 24, 2001 2:33 PM
Subject: Re: [REBOL] Re: Rebol/command, fastCGI, session id, frames, etc....
> On Sun, 24 Jun 2001 13:50:35 +1000
> "Allen Kamp" <[allenk--powerup--com--au]> wrote:
>
> > > 2. store session id in session table with time stamp
> >
> > Graham,
> >
> > This is the point at which session handling does not
> > scale well. The moment
> > you track anything on the server, you are reducing the
> > scalability. Also
> > with a web app in largescale webfarm with load balancing
> > there is no
> > guarantee that the same server will handle the next
> > request from the client.
>
> Hi Allen,
>
> I just don't see this. I track sessions in my website using
> a sql table. I only have the one server, but if I had
> multiple servers, they only need access the single session
> sql table.
>
> > (Though there are some tools that try to make this happen
> > with varying
> > success)
> >
> > In ASP, sessions become even more dangerous to this
> > scalability as it makes
> > incedibly easy and seductive to use variables within a
> > session context. So
>
> And all my variables are stored as objects within the
> session table in a varchar field.
>
> --
> Graham Chiu
>
The ASP model I'm talking about from ms IIS which is dangerous is holding
all those session vars in memory. ouch! Some developers even store entire
pages in a session var.
Graham what you are doing is fine. However you must also be aware that each
open connection to the db has a memory and look up time hit too. When does
the clean up happen? and is there a time/cycles cost there? Probably not a
big problem
Cheers,
Allen K
