--- In firebird-php@yahoogroups.com, 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

between

> requests (normally) as long as a browser is open but that depends on the
> session cookie parameters that are used... the persitence of 'state'

(i.e.

> 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

values,

> > 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.

Myles