Комментарии 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 не работал, может кто подскажет тут. Может даже Вы?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.