В нашем PHP-проекте есть сценарий обслуживания, который запускается через определенные промежутки времени и выполняет ряд задач на основе отдельных расписаний, думайте об этом как CRON
для php.
Проблема, с которой я сталкиваюсь, заключается в том, что некоторые задачи, которые возникают через определенные промежутки времени, выполняются в течение периодов, превышающих продолжительность нашего усиленного сеанса (30 минут), и поэтому срок действия сеанса истекает в ходе этой задачи, что преждевременно завершает работу.
К вашему сведению: я не говорю об ограничениях времени выполнения скрипта, мы уже используем set_time_limit()
, чтобы разрешить длительные процессы.
Вопрос: есть ли способ "прикоснуться" к сеансу во время выполнения скрипта таким образом, чтобы сбросить время истечения сеанса? т. е. подходит ли настройка переменной сеанса или для этого требуется специальная функция PHP?
Чтобы быть более конкретным, у нас есть одно фактическое задание CRON
, которое выполняется каждую минуту:
* * * * * user curl -XGET https://domain.com/maintenance.php
... который, в свою очередь, использует нашу внутреннюю систему для поиска задач, запланированных для запуска в это время, некоторые из этих задач короткие и простые, некоторые длинные и сложные. Вышеупомянутая проблема возникает во время длинных сложных (> 30 минут выполнения).
EDIT: Подводя итог многочисленным комментариям ниже...
Мы хотим избежать выдачи дополнительных RPC для достижения этой цели, я ищу решение, подобное воображаемому
touch_session()
.Я считаю, что мы можем исключить возможность изменения значений сеанса, потому что изменения не записываются в сеанс до тех пор, пока запрос не будет закрыт, что в нашем случае уже слишком поздно.
Мы используем БД для управления сеансом, поэтому мы могли бы просто написать собственный метод
touch_session()
, который можно вызывать и просто использовать SQL-запрос для обновления метки времени а-ляUPDATE sessions SET expiration = '###' WHERE Session_ID = 'abc123';
. Есть ли в этом подводные камни?
Если нет ни одного из вышеперечисленных, есть ли другие варианты, которые не требуют дополнительных rpc?
CURL
, которые требуют, чтобы сеанс оставался в силе, это может произойти позже во время выполнения родительских сценариев, и поэтому срок их действия истекает к тому времени, когда они появляются. Сеанс содержит информацию, необходимую для проверки разрешений. - person oucil   schedule 26.03.2014$_SESSION
должен оставаться неповрежденным, даже если запись данных сеанса удаляется сборщиком мусора, и должна восстанавливаться при завершении работы во время выполнения. - person Gumbo   schedule 26.03.2014touch
сеанс. - person oucil   schedule 26.03.2014data
, но какой в этом смысл, если срок действия сеанса истек и он больше не может получить доступ к защищенным ресурсам, необходимым для выполнения его работы? Простой факт заключается в том, что сеанс должен оставаться активным на протяжении всего процесса независимо от времени, поэтому мне нужно что-то, чтобы коснуться временной метки сеанса. Я пытаюсь избежать необходимости выполнять вызов CURL каждые N записей в течение длинного цикла, и, таким образом, мы возвращаемся к моему вопросу: достаточно ли обновить значение переменной сеанса или есть вызов функции. Если оба они ложны, есть ли другой вариант? - person oucil   schedule 26.03.2014$_SESSION
. Данные должны быть сохранены обратно при завершении работы во время выполнения (session_write_close
). Только если вам потребуется еще один вызовsession_start
в уже истекшем сеансе, вы получите пустой$_SESSION
. - person Gumbo   schedule 26.03.2014CURL
для запуска задач, и поэтому, пока родительский процесс будет продолжать работать и иметь доступ к действительному сеансу, поскольку он все еще работает , любые удаленные вызовы дочерних задач, которые предполагают, что действительный сеанс все еще активен, завершатся ошибкой из-за удаления данных сеанса. - person oucil   schedule 26.03.2014