Hi Stas, On Mon, Feb 1, 2016 at 8:44 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: >> Consequences >> - If script executes session_commit()/session_destroy()/use read only >> option, PHP will not perform GC. i.e. GC function is not called at >> all. Therefore, probability of GC decreases and GC becomes less >> likely. >> - If script uses multiple session storage, only the last session >> storage performs GC. i.e. Previously used session storage may not call >> GC function at all if this is done for site wide. >> - User will not see occasional page rendering delay by GC. (This is >> the main reason of this change) > > This doesn't look very good. This has potential to break GC for some > applications, especially high-performance ones which are likely to use > read-only mode, and thus for them GC is needed. > > I also don't understand why you need this to avoid delay. Right now GC > is performed on shutdown, doesn't it? If it's performed on shutdown, it > would not delay rendering. I'm not sure I understand why you need to > condition this on session being active or not active. Please explain.
As far as I remember, session module performed GC at session_start() from the beginning it is introduced because module cannot know used save handlers, save path, session name (this could affect GC on some save handlers) at shutdown. So when GC is performed, user experiences delayed response due to GC. This could be few seconds to minute for files handler. For normal setups, apps use single configuration for session, GC is done. If there is multiple session config, module cannot issue GC except the last one used with this change. We may save used config for GC. I'm not sure if it's worth doing it. This RFC uses timestamp for expiration, if GC is performed or not does not matter. The only problem is growing number of garbage in session storage with multiple session config in a application. This could be documentation issue. Users are better to use cron task for GC for better user experience anyway. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
