14 мая 2012 г.

Очистка Zend_Cache по расписанию

Часто бывает, что некоторую информацию можно хранить в кеше вечно, инвалидируя её только непосредственно при обновлении (в моём случае - по расписанию).
Казалось бы, какие проблемы? Кроновские скрипты написаны в контексте зендовского приложения, кеш подключается автоматически - осталось только взять да почистить по тегам методом clean().
Но не тут то было! 


Для начала пришлось поправить права для файлового кеша. Поскольку создаётся он сайтом (пользователем вебсервера), а удаляется из под крона (от имени владельца крона).
Соответсвующие опции кеша проставляются примерно так:
resources.cachemanager.NAME.backend.options.hashed_directory_umask = 0777
resources.cachemanager.NAME.backend.options.cache_file_umask = 0777
где NAME - имя вашего кеша.

Вторая трабла случилась непосредственно при попытке удаления записей. Метод clean() возвращает положительный результат и всё как бы хорошо, пока не замечаешь, что кеш то не очищен (Оо).
Благо сорцы копать не привыкать, поэтому вот он, чудесный кусочек метода clean():
class Zend_Cache_Core {
    public function clean($mode = 'all', $tags = array())
    {
        if (!$this->_options['caching']) {
            return true;
        }
        ...clean...
    }
} Как видите, метод не будет производить чистку, в случае отмены кеширования.
В моих кроновских скриптах, до очистки кеша, происходит множество действий с моделями, некоторые методы которых могут оказаться закешированы вызовом с клиентской стороны.
Для того, чтобы подстраховаться от сложно-воспроизводимых багов, было решено отменить кеширование для некоторых кешей в случае запуска из консоли (у меня там отдельная секция в application.ini). Это и привело к тому, что кроновские скрипты не могут почистить кеш =(

Мне, признаться, искренне не понятен смысл такой проверки перед очисткой, но решил таки перепроверить все вызовы моделей из крона и включить кеширование обратно (вместо наследования и переопределения).

Комментариев нет: