Как вручную управлять транзакциями в Doctrine?

Question

[HellWalk]

Не понимаю как управлять транзакциями в Doctrine.

Допустим, что у нас есть воркер который слушает очередь и обрабатывает данные. Пример обработки 3-х запросов:

for ($i = 0; $i < 3; $i++) {

            $this->entityManager->getConnection()->beginTransaction();

            $entity = new OrderLog(); // entity для примера

            $entity->setRequest('request');
            $entity->setResponse('response');

            // ...какая-то другая логика и сущности

            $this->entityManager->persist($entity);
            $this->entityManager->flush();

            if ($i === 1) {
                // На втором запросе происходит ошибка и нужно сделать откат
                $this->entityManager->rollback();
            } else {
                // В остальных случаях все ок и делается коммит
                $this->entityManager->commit();
            }
        }

На третьей итерации получаю ошибку:

Doctrine\DBAL\ConnectionException: Transaction commit failed because the transaction has been marked for rollback only

Посмотрел официальную документацию, там очень расплывчатый комментарий на эту тему:

However, a rollback in a nested transaction block will always mark the current transaction so that the only possible outcome of the transaction is to be rolled back. That means in the above example, the rollback in the inner transaction block marks the whole transaction for rollback only. Even if the nested transaction block would not rethrow the exception, the transaction is marked for rollback only and the commit of the outer transaction would trigger an exception, leading to the final rollback. This also means that you cannot successfully commit some changes in an outer transaction if an inner transaction block fails and issues a rollback, even if this would be the desired behavior (i.e. because the nested operation is optional for the purpose of the outer transaction block). To achieve that, you need to resort to transaction nesting with savepoint.

All that is guaranteed to the inner transaction is that it still happens atomically, all or nothing, the transaction just gets a wider scope and the control is handed to the outer scope.

Складывается впечатление, что доктрина писалась только для обработки обычных http-запросов, когда в случае ошибки можно бросить исключение сделать rollback и на этом все закончить.

Хотелось бы узнать, как пример кода выше заставить работать.

Comments

[tukreb]

Вы пытаетесь микроскопом забивать гвозди.
Нужно не откатывать транзакции только потому что, она всегда падает, а сделать так, чтобы её не нужно было откатывать вообще.
Найдите почему происходит откат и справьте это.

[HellWalk]

tukreb,

Найдите почему происходит откат и справьте это.

Вы в курсе что такое транзакции и для чего они применяются? Почему такой функционал потребовался в базах данных?

[tukreb]

HellWalk, конечно, но судя по вашему коде, вы всегда знаете, когда она должна произойти, что явно намекает, что тут что-то не так в вашем коде.

[HellWalk]

tukreb, вы реально не догоняете, что это код для примера?

Answer 1

[Дмитрий Гординский]

Складывается впечатление, что доктрина писалась только для обработки обычных http-запросов

Правильное впечатление.
В таких случаях стоит явно пересоздавать EM после ролбэков.
HOW TO recover from rolled back transaction

Comments

[HellWalk]

Нашел аналогичное решение сам, зашел на тостер написать ответ, а вы уже опередили)

Получается что с самим EntityManager лучше на прямую не работать, а написать обертку, которая также будет реализовывать EntityManagerInterface, а внутри себя будет работать с EntityManager и перепроверять, активно ли соединение с базой:

public function persist($object): void
    {
        if (!$this->entityManager->isOpen()) {
            $this->doctrine->resetManager();
            $this->entityManager = $this->doctrine->getManager();
        }

        $this->entityManager->persist($object);
    }

    public function flush(): void
    {
        if (!$this->entityManager->isOpen()) {
            $this->doctrine->resetManager();
            $this->entityManager = $this->doctrine->getManager();
        }

        $this->entityManager->flush();
    }

Забавно, что я это понял через 3 года работы с симфони.