История изменений
Исправление korvin_, (текущая версия) :
И к моменту начала транзакции какая-то проверка стала ложна из-за другого пользователя.
Ага.
Но ты об этом уже не узнаешь и спишешь в минус деньги со счёта, остатки со склада и т.д.
Узнаю, потому что updated_at поменялся этим другим пользователем и affected rows при моём апдейте будет 0. Конечно, это нужно проверять внутри транзакции и отменять её.
Или ты про то, что updated_at должно работать как виртуальная транзакция и обновляться при каждой операции?
Да, этакий optimistic lock.
Соответственно, получая ошибку, пробуем повторить весь flow, начиная с селектов. С каким-то лимитом повторов. Звучит как будто оверхед, но это может помочь сократить время и область транзакций и/или блокировок в БД, а приложение отмасштабировать проще. Да и случаев, когда миллионы пользователей пытаются во так конкурентно, одновременно изменить общий ресурс, не так много.
Видел подобное на практике в достаточно популярном сервисе, работает. Исчерпание лимита повторов почти никогда не происходило. Впрочем, там было довольно мало общих ресурсов с большим количеством пользователей. Так что не везде может подойти, да.
Исправление korvin_, :
И к моменту начала транзакции какая-то проверка стала ложна из-за другого пользователя.
Ага.
Но ты об этом уже не узнаешь и спишешь в минус деньги со счёта, остатки со склада и т.д.
Узнаю, потому что updated_at поменялся этим другим пользователем и affected rows при моём апдейте будет 0. Конечно, это нужно проверять внутри транзакции и отменять её.
Или ты про то, что updated_at должно работать как виртуальная транзакция и обновляться при каждой операции?
Да, этакий optimistic lock.
Соответственно, получая ошибку, пробуем повторить весь flow, начиная с селектов. С каким-то лимитом повторов. Звучит как будто оверхед, но это может помочь избежать долгих транзакций и/или блокировок в БД, а приложение отмасштабировать проще. Да и случаев, когда миллионы пользователей пытаются во так конкурентно, одновременно изменить общий ресурс, не так много.
Видел подобное на практике в достаточно популярном сервисе, работает. Исчерпание лимита повторов почти никогда не происходило. Впрочем, там было довольно мало общих ресурсов с большим количеством пользователей. Так что не везде может подойти, да.
Исходная версия korvin_, :
И к моменту начала транзакции какая-то проверка стала ложна из-за другого пользователя.
Ага.
Но ты об этом уже не узнаешь и спишешь в минус деньги со счёта, остатки со склада и т.д.
Узнаю, потому что updated_at поменялся этим другим пользователем и affected rows при моём апдейте будет 0. Конечно, это нужно проверять внутри транзакции и отменять её.
Или ты про то, что updated_at должно работать как виртуальная транзакция и обновляться при каждой операции?
Да, этакий optimistic lock.
Соответственно, получая соответствующую ошибку, пробуем повторить весь flow, начиная с селектов. С каким-то лимитом повторов. Звучит как будто оверхед, но это может помочь избежать долгих транзакций и/или блокировок в БД, а приложение отмасштабировать проще. Да и случаев, когда миллионы пользователей пытаются во так конкурентно, одновременно изменить общий ресурс, не так много.
Видел подобное на практике в достаточно популярном сервисе, работает. Исчерпание лимита повторов почти никогда не происходило. Впрочем, там было довольно мало общих ресурсов с большим количеством пользователей. Так что не везде может подойти, да.