Как вы относитесь к использованию транзакций в Laravel?

Question

[Александр Шведов]

Как вы относитесь к использованию транзакций в Laravel?
Скажем есть важная информация и чтобы ее не потерять использовать транзакции для повторного пересохранения насколько это правильно с точки проектирования
Для примера такой подход

try {
    DB::transaction(function() {
        // ... снова и снова
    }, 3);  // Повторить три раза, прежде чем признать неудачу
} catch (ExternalServiceException $exception) {
    return 'Извините, внешняя служба не работает, а вы не сможете завершить регистрацию без ключей от нее'.
}

Answer 1

[Alex Wells]

Мы на проекте решили использовать транзакции везде, кроме роутов только на выборку. В том числе и в джобах.

Транзакции стопроцентно нужны, так как они позволяют не записывать полу-состояние (и.е. откатить все что можно, если какой-то из запросов или какая-то бизнес логика выкинули эксепшен) и не ломать этим базу. Это главная причина, почему мы везде их юзаем.

Есть минус - дедлоки. По-нормальному это решается какой-нибудь doctrine, либо повтором транзакций (если реально), либо фиксами долгих транзакций.

Comments

[Александр Шведов]

Ну я поставил 3 повтор и вслучае ошибки except само использование транзакции возникло из за краша по неизвестным причинам в 1 из 1000листов я думаю это может решить проблему и сохранить данные просто при создание сущности юзер выставляются сразу связи с заполнением основная логика чтобы если чтото сломалось то состояние отменилось и база неломалась
Вопрос в 1 сколько максимально можно ставить повторов?

[Alex Wells]

constintmid, сколько захотите. Желательно 0.

Answer 2

[vism]

Использовать надо, другие описали, а еще я бы добавил, что помимо транзакции в операции могут быть events, которые тоже надо откатить (не выполнять).
Для этого используется пакет
https://github.com/fntneves/laravel-transactional-...

Comments

[Александр Шведов]

А job этим же откатывать?

[Alex Wells]

Угу, у нас в проекте такое же самодельное решение.

[Alex Wells]

constintmid, да, нужно. Хз умеет ли это делать этот пакет.

[vism]

constintmid, для job https://github.com/therezor/laravel-transactional-jobs, но вобще "по правильному" Jobs через ивенты запускать

[vism]

но его работу я не проверял

[Александр Шведов]

vism, Логично просто не так часто job запускаю

Answer 3

[xfg]

Транзакции повторяют из-за дедлоков. Это такое состояние, когда одновременно выполняются 2 транзакции и первая транзакция блокирует запись, которая нужна второй транзакции, а вторая транзакция блокирует запись, которая нужна первой транзакции. В итоге ни одна из транзакций не может завершиться. Это состояние называется deadlock. В этом случае одна из транзакций должна откатиться, чтобы другая имела возможность успешно завершиться. Так вот, эта транзакция, которую откатили попробует еще 3 раза выполниться, прежде чем окончательно вылетит с исключением.

Соответственно, да, если у вас толстые транзакции, то желательно их повторять, так как чем более жирная транзакция и чем больше выполняется одновременных транзакций в единицу времени, тем выше шанс получить deadlock.

Вообще на более продвинутом уровне принято сохранять не более одной сущности (объекта) внутри одной транзакции. Таким образом вы получаете худые транзакции и отсутствие дедлоков. Производительность вашего приложения возрастет, но вместе с тем, вы получите проблему атомарного сохранения нескольких сущностей (объектов) в рамках одной бизнес-операции как это происходит в микросервисной архитектуре. Проблему можно решить использованием шаблона saga, но в целом это уже совершенно иной уровень знаний и вникать в это наверное не стоит, если вы делаете что-то небольшое.

Comments

[Alex Wells]

Можно не повторять, а комиттить одну быструю (и любого размера) транзакцию в самом конце, как делает доктрина.

Либо не заниматся херней минуту после апдейта какой-то записи, а поменять порядок/вынести в джобу.

Оба решения вполне себе справляются с проблемой.

Спасибо за SAGA, хотя я не вижу разницы с транзакциями на много сущностей. Тоже самое, только теперь у каждого своя транзакция и откатываются они отдельно. Я не прав?

[xfg]

Alex Wells, да, всё верно, только в saga не откатывают, а компенсируют. Отличие в том, что rollback - это техническая штука, которая случается при ошибках в инфраструктуре. Компенсация - это бизнес штука, которая случается, если было нарушено бизнес-правило. Классический пример - бронь путешествия. На первом шаге бронируем отель, на втором шаге пытаемся купить билет на самолет, но сервис отвечает отказом, так как билеты на эту дату уже распроданы. Теперь требуется отказаться от бронирования отеля. Это и делает компенсирующая транзакция. То есть здесь нет технических ошибок, здесь есть только бизнес-правило не позволяющее дальше продолжать цепочку действий, поэтому она прерывается и начинает идти в обратном направлении. Соответственно компенсация - это не обязательно шаг строго обратный транзакции, в отличии от rollback. При технических ошибках, сага падает и остается не завершенной, такие ситуации нужно анализировать и исправлять код, чтобы сага всё же смогла придти к завершенному состоянию.

По поводу doctrine, я так понимаю имеется ввиду шаблон Unit of Work. Он к сожалению не решает проблемы дедлоков. Они в любом случае будут возможны. Чем больше сущностей внутри транзакции и чем чаще происходят эти транзакции, тем выше вероятность получить deadlock. Можно погуглить doctrine deadlock, чтобы в этом убедиться. Эту проблему не возможно решить какой-либо библиотекой, просто потому что так устроены сами ACID-транзакции. Doctrine может лишь скрыть эту проблему от пользователя используя например ретраи. Unit of Work просто позволяет не держать транзакцию открытой, а открыть её только в тот момент, когда мы готовы сделать коммит.

Но всегда, всё имеет свои компромиссы. Saga значительно повышает сложность проекта, но фактически является де-факто в распределенных системах.

[xfg]

Alex Wells, извини за простыню :)

[Alex Wells]

xfg, спасибо за ответ)

Answer 4

[Karpion]

Необходимость использовать транзакции - определяется задачей, а не средствами её решения.

У транзакций есть два свойства:

1. Транзакция либо доходит до конца, либо как будто не начинала выполняться (реально - она начинает что-то делать, но это инвариантно тому, как будто она ничего не сделала; а в какой-то момент она оказывается сделанной целиком). Это нужно при работе с энергонезависимым накопителем - на случай сбоя питания.
   
2. Транзакция не позволяет никому трогать те элементы, которые она использует. Ну как "никому"... другим транзакциям... просто никто третий туда залезть не может. Это нужно при работе многих потоков с одной БД.
   

И если нужно хотя бы одно из этих свойств - то транзакции нужны. А при однопоточной работе с данными в памяти - не нужны.