Re: [RFC][Discussion] Add session_gc()

From: Date: Mon, 18 Apr 2016 18:55:41 +0000
Subject: Re: [RFC][Discussion] Add session_gc()
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-92424@lists.php.net to get a copy of this message
Hi! >> Document calling session_gc() periodically is the best practice. > > If you want to document usage of this new API as the best practice, it > would be unfair to the users if you don't also document the caveats that > come with it: I also think it's wrong to document it so. While having periodical GC is the best practice, probabilistic GC *is* calling GC periodically. True, for some exceptional scenarios - like sites with very low traffic - the period is unpredictable. And *then* it's recommended to explicitly call session_gc(), and for these cases it is a great addition. But in a typical medium or high traffic site the period is very predictable as as such there's no way to document otherwise. > probability-based behavior (and how to do that; based on my > observations, the vast majority of users don't know how GC is triggered > at all) And that's great BTW since majority of users don't need to know that - it just works. We shouldn't ruin that. > - Trigger warnings when session_gc() is called while gc_probability is > not 0. This does not sound like a good idea to me. Why we should make it harder for people to use it together? session_gc() has nothing to do with gc_probability. > - To avoid re-activating expired sessions, trigger warnings when > session_gc() is called after session_start() Last time I've looked at the patch, session_gc() was required to be called after session start. See: https://github.com/php/php-src/pull/1852/files#diff-2e4264d70a35458a2241e27f76f4a93cR20 I think this is wrong (see my comments there) and in fact we should not expose this complexity to the user - gc() should just do the GC and hide the technical details. -- Stas Malyshev smalyshev@gmail.com

« previous php.internals (#92424) next »