On 10/6/09 10:26 AM, "Il pinguino volante" <tuxsoul@xxxxxxxxxxxxx> 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: http://www.php.net/manual/en/function.session-set-save-handler.php 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 complex. 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. http://phpslacker.com/2009/03/02/php-session-clustering-with-memcache/ 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
