Комментарии 12
В том и дело, что бага нет.
Но почему-то люди привыкли, что gc_maxlifetime — это время жизни сессии, хотя это далеко не так
Но почему-то люди привыкли, что gc_maxlifetime — это время жизни сессии, хотя это далеко не так
session_destroy() так не думает.
Этот параметр отвечает за время, после которого приложение гарантированно не использует сессию с таким идентификатором, а значит она потенциально может быть удалена.(см. документацию)
Этот параметр отвечает за время, после которого приложение гарантированно не использует сессию с таким идентификатором, а значит она потенциально может быть удалена.(см. документацию)
GC запускается каждый раз при вызове session_start(). На больших проектах много сессий и соответственно это дополнительные потери времени, которые нельзя игнорировать т.к. влияют на время ответа.
У меня GC отключен и принудительно запускается отдельным скриптом по cron. К сожалению в PHP много таких старых проблем.
У меня GC отключен и принудительно запускается отдельным скриптом по cron. К сожалению в PHP много таких старых проблем.
Первый раз вижу такое применение GC. O_o
Документация же описывает, что обьекты будут помечены, как мусор и возможно произойдёт освобождение памяти.
Документация же описывает, что обьекты будут помечены, как мусор и возможно произойдёт освобождение памяти.
Самое смешное, что нет гарантии что gc уберёт сессию, в дебианах был отдельный баш скрипт, который чистил сессии, а gc вовсе их не чистил. Не копал из-за сухосина это или ещё от чего-то, опытные разработчики знают, что если хочешь быть уверенным в результате, то нужно это делать самому.
GC был специально отключен, так как не мог работать из-за принятых мер по повышению безопасности. На /var/lib/php5 выставлены права, не позволяющие получить список файлов, и тем самым узнать доступные идентификаторы сессий. Плюс гарантия, что сессия будет уничтожена, даже если запросов со стороны клиентов не поступало.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Неожиданное поведение Garbage Collector'а сессий