Комментарии
15
Почему отказались от использования очередей? В случае, если одна задача — один процесс, проблем бы с менеджером не было
Не совсем понимаю, как влияет наличие или отсутствие очередей на работу с ORM?
Я к тому, что, мне кажется, эта задача решается проще, выделением блока try-catch в отдельный процесс, т.о. ошибки в одной из задач не будут влиять на другие. Что-то вроде
while (!$this->isShuttingDown()) {
$task = $this->taskProvider->getNextTask();
// fire and forget
$this->producer->runTask($task);
}В статье преведены примеры проблемы в том числе и с try..catch, который к самой проблеме имеет весьма посредственное отношение. Суть в том, что менеджер документов это своеобразный реестр. Об этом тоже в статье есть :)
Если я правильно понял статью, то проблема в долгоживущем скрипте, который накапливает ошибки если ObjectManager — это синглтон.
Если бы скрипт обрабатывал таски по одному и умирал при исключении — этой проблемы не было. А "повреждённые" таски выглядят как классические failed или delayed messages в терминах message broker.
Так или иначе даже в случае исключения бывает необходимо записать информацию в базу данных. Например, если в ходе обработки видео-файла мы поняли, что он поврежден.
Согласен, эту задачу очень легко решить правильно изолировав обработку задачи.
Это статья не про очереди, а про работу с доктриной в целом, в примере у меня про задачи (Task), но на деле это может быть что угодно. Вы сейчас говорите, что эту задачу в частном случае можно было решить «вот так», а я говорю вам про общий случай.
IMHO, проблема в том, что try-catch находится не там, где должен. Он должен быть внутри someService. Чтоб после вызова runTask все сущности имели валидное состояние, которое спокойно можно зафлашить. А у вас логика обработки ошибки утекла из сервиса, который собственно и знает какие сущности он сделал MANAGED.
Если так рассуждать, то получается сервис не имеет права кидать исключения. И как он в таком случае будет сообщать об ошибке клиентскому коду?
Присмотритесь, в вашем примере исключение используется для управления потоком. Это ничем не отличается от условного goto ERROR_HANDLER;
Исключение из сервиса конечно могут выбрасываться, но только в том случае, если сам сервис не может их решить. Но в таком случае вообще не понятно что в данных и сейвить их бд чревато. Лучше не сейвить ничего и попробовать позже повторить операцию.
Исключение из сервиса конечно могут выбрасываться, но только в том случае, если сам сервис не может их решить. Но в таком случае вообще не понятно что в данных и сейвить их бд чревато. Лучше не сейвить ничего и попробовать позже повторить операцию.
Это все спорно и скорее всего это тема для отдельного холивара. Не плохо было бы если Вы сослались на авторитетный источник. К примеру автора подобного заявления заминусовали на здесь на хабре habr.com/ru/post/476142
Здравый смысл достаточно авторитетный источник?
А чем эти сессии отличаются от обычных транзакций?
В Doctrine ODM не транзакций.
В Doctrine ORM есть, но судя по документации «в случае пожара» нужно закрыть EntityManager, правда что с этим дальше делать не ясно. Я с ORM не работал, может кто подскажет тут. Может даже Вы?
В Doctrine ORM есть, но судя по документации «в случае пожара» нужно закрыть EntityManager, правда что с этим дальше делать не ясно. Я с ORM не работал, может кто подскажет тут. Может даже Вы?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Проблемы использования Doctrine ODM в процессах-демонах