At 3:53 PM +0000 3/18/11, Stuart Dallas wrote:
Hi Tedd,

Long time no chat, hope you're well.

On Friday, 18 March 2011 at 15:44, tedd wrote:
 At 3:18 PM +0000 3/17/11, Stuart Dallas wrote:
 > > Pragmatically speaking though, I'd say go for database backed
 > sessions until
 > > they actually become a performance bottleneck.
 > -snip-
 > This may also be of interest:
 > -Stuart
 > --
 > Stuart Dallas


 I'm not getting the reason for storing a session in a db.

If your site is being served by multiple servers you need centralised storage of session data rather than the PHP default of using files. Either that or the load balancer needs to use sticky sessions which can lead to other issues depending on your traffic patterns.

My alternative to that is to bounce the minimum amount of data necessary between the browser and server with each request.

 In the scripts I have written that remember the user (i.e., "Hi
 Stuart"), I simply use a cookie stored on the user's computer.
 Sometimes it's just their name and other times it could be what/where
 they visited, or how they set their defaults, or any number of
 things. But everything that is needed and doesn't require
 authorization is set in a cookie that expires within a specific
 length of time -- usually a year.

 I don't see a need for storing session in the above case.

That would be because there isn't one, but you'd be surprised how often sessions are used for this type of thing.

 If the scripts require an authorization, then I use sessions and a
 timer in concert. As long as the authorized user remains logged-in
 and the visit remains active, then the user enjoys the benefits of
 the visit.

 If the authorized user times out, then the session is destroyed and
 the user is asked to log-in again, generating another session.

 If the authorized user leaves the session (closes the browser) then
 everything is closed (session destroyed) and sometimes a cookie
 remains on the user's computer preparing for the next visit.

 The next time the user visits the site, everything (if anything) that
 is stored in user's cookie is addressed. But the user is asked to
 log-in again and another session is generated.

 In all cases where there is sensitive data, the user must log-in
 generating a new session.

Again, I don't see how storing the current/past session provides any benefit.

 So, what am I not understanding or missing?

 Please show me how reactivating (if that is what this is) a session
 does anything.

I don't recall anyone saying anything about reactivating old sessions. The cookies I use to replace sessions are session-based cookies and last no longer than a traditional PHP session. The key is to provide a lightweight method of ensuring that whichever server processes the request has access to the session data.


Thanks Stuart.

You are always a couple of light years ahead of me. I'll have to study what you provided.




PHP General Mailing List (
To unsubscribe, visit:

Reply via email to