On 10/6/09 10:26 AM, "Il pinguino volante" <tuxs...@codeinside.it> wrote:

> I have to realize an authentication system for a lot of users.
> I heard that someone uses to store session states (?) into a database. I'd
> like to know how and, expecially, WHY to do it and what's would be better
> (considering that I CANNOT -d'oh!- edit the php.ini file).

i think you can modify the PHP session handler without touching php.ini:

i've read a lot on the web about this in recent weeks. different people
offer their own justifications for the various approaches to session
handling: PHP's file handler, user DB methods for the PHP session handler,
PHP's memcache handler, zend session clustering, or do it yourself and don't
use PHP sessions at all.

there's a lot of controversy on the topic because different people have
different requirements and preferences. so your question WHY? is quite

my motivation for considering user DB back-end to the PHP session handler
was that it would replicate the session data over the DB cluster. retaining
the PHP session front-end means less code rework and you keep its session
locking. but it adds DB load, and the DB is often an app's bottleneck.
whether or not that's ok depends on app specifics.

i looked at memcache but i have two problems with it. one is that it is a
cache system so it's not designed to be reliable: if it runs out of memory,
restarts or crashes, the sessions are gone. the other is that the PHP
session implementation is barely documented. i couldn't figure out how it
implements the clustering (does it?) so i couldn't see how i would implement
failover, recovery and maintenance procedures.

one class i saw used memcached combined with DB in case of cache miss. it
speeds up the reads but every write goes to both cache and DB.

one thing that obviously helps is don't write the session to the DB if it
hasn't changed. i'm not sure how best to do that yet. and you can optimize
the writing of the session timestamp to the DB too.

then there's the question of whether or not to use one DB connection for
both session handling and the main app or use two connections. the latter is
easier to code.

row locking in the session table would be preferable to table locking.

maybe we should work together on the code for all this?

there's a webinar on zend platform session clustering that discusses various
issues, bearing in mind it's a technical sales pitch. i don't think it's
entirely fair to the DB methods.

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to