[Fwd: Sessions in databases]

(There were some erroros in the previous email, I'm sorry)

Hi to all.

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

Thanks in advance,
Alfio.




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

Re: [Fwd: Sessions in databases]

If you are distributing your application over multiple servers, using a
database for session tracking allows a user to continue there session
regardless of which server their request bounces too. It prevents the
need for 'sticky' network connections which time out anyways. Databases
can make scaling applications to enterprise size considerably easier.
There are other file based solutions that are dirty and require you to
play with file locking and all that nastyness.

You also don't need access to the php.ini file to implement session in a
database, check out http://php.net/session_set_save_handler

Il pinguino volante wrote:
> (There were some erroros in the previous email, I'm sorry)
>
> Hi to all.
>
> 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).
>
> Thanks in advance,
> Alfio.
>
>
>


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

Re: [Fwd: Sessions in databases]

On 10/6/09 10:26 AM, "Il pinguino volante" 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-handl er.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

Re: [Fwd: Sessions in databases]

Sam Stelfox wrote on 2009-10-06 18:09:
> If you are distributing your application over multiple servers, using a
> database for session tracking allows a user to continue there session
> regardless of which server their request bounces too. It prevents the
> need for 'sticky' network connections which time out anyways.

I know Alfio don't have access to the php.ini file, but if you do and
have the above setup, consider using a tmp dir like /phptmp and have one
root server and mount the other servers /phptmp to the root servers /phptmp

Kind regards
Kim Emax

> Il pinguino volante wrote:
>> (There were some erroros in the previous email, I'm sorry)
>>
>> Hi to all.
>>
>> 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).
>>
>> Thanks in advance,
>> Alfio.
>>
>>
>
>


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

Re: [Fwd: Sessions in databases]

Il pinguino volante wrote:
> (There were some erroros in the previous email, I'm sorry)
>
> Hi to all.
>
> 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).
Considering you cannot edit the php.ini-file i suspect you are on a
shared host. Using the database for intense work in a shared environment
is not always popular. I would guess that file based session-files are
more scalable. And as you are using a shared hosting service you are
probably not load balanced between physical different boxes and this
would not gain from using the DB.
So if you have to manage a large number of user sessions i would suggest
you choose a VPS or deducated/colo box and then use DB with memcached in
between for fast caching. That is the way i have done it for a couple of
sites i am working on.



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