Subject Re: Firebird php session handling functions?
Author vladman992000
--- In, Jochem Maas <jochem@...> wrote:
> > Let's start with the purpose of a Session. My understanding (and
use) is so
> > that I can keep semi-persistent data created in a web page
available between
> > the client and the PHP server, as the client moves from page to page.
> > Basically it's the same as some form of persistent variable
storage that
> > moves through the client's application experience. Is this
correct in your
> > opinion?
> yes and no.
> the session mechanism serves as a means to allow 'state' to persist
> requests (normally) as long as a browser is open but that depends on the
> session cookie parameters that are used... the persitence of 'state'
> data/settings/etc) is (as far as the php session is concerned)
purely restricted
> to the server. session data is not available or shared with the client
> (of course one can pass data stored in the session to the client by
including the
> values in the [html] output somehow).

OK. Thanks for the expanded explanation. I think this is consistent
with my understanding of its philosophy, and so far I think I'm being
safe in my use of sessions in my app then.

> > Finally the main use of sessions that I understand is to try and
make a
> > browser work like a persistent client application would, so that
data isn't
> > lost between page requests. This data could be stored in a variety of
> > places other than sessions, however. Like form variables, URL GET
> > etc. A session is mainly a convenience for this. Is this correct?
> yes but it's more than a convienience - assuming that your server
has not been
> comprimised you can be sure that the data in the session is safe and
what you store
> there is unknown to the client/user which is not the case when you
pass information
> around via GET, POST or COOKIE. (session fixation and session
hijacking are seperate
> issues of course)

OK. I definately agree that its a better way to keep persistent data
moving between pages. But as the user could quit their browser at
anytime, I'm still considering it a 'temporary' way to handle data.
Kinda like a global variable set that only exists in memory in an
application while the application is alive.

> > Now back to the original posters question about implementing
sessions with
> > Firebird. My point was why?
> agreed. although php allows replacement of the default session
handling mechnism
> with session_set_save_handler() it's generally not worth the effort
- the default
> filebased handler is fast, making it faster is generally a question
of using
> a ramdisk (e.g. tmpfs)

I've been using an extension of the PHP Session handling in Code
Igniter called 'PHPSession' that was a user contributed class. Its
been fine and reliable for my purposes, but when the original poster
had asked about storing sessions to a database, that's where I was
stumped. Sounds like I wasn't the only one. Not that it was to do
with my misguided understanding of the underpinnings of a session, but
more to do with the relevance of a session storing this level of
persistent data for a site. I can see, however, as you rightly point
out that on high volume sites, a DB might provide a faster mechanism
for handling this type of data, but again its all temporary.

> a better reason for using a database as the session storage
mechanism is that
> it potentially allows sharing session data between multiple frontend
servers for
> high capacity sites where incoming requests can be handled by one of
any number of
> webservers (and there is no garantee that a client's requests will
be dealt with by
> a single server.

Ah. This is an important point. Yes, if multiple web servers are
being used and one's application is using Sessions, then if the user
gets routed to a different web server to handle the request (due to
load balancing, etc.) it would need to be able to read the session
information from a database. I see an important capability here.

I guess then it comes down to whether this model of load is likely to
be the case in the original poster's intention. If so, yes - storing
sessions in FB would make sense. If not, its probably a moot point.

Thanks again for your expanded explanation. It does really help.