Интервьювер душит deadlock’ом. 🐘Отвечаем так:Precondition: У нас с тобой есть две конкрурентные транзакции, которые что то меняют, и мы уже такие молодцы заюзали UPDATE с блокировкой строк. В качестве примера возьмем ситуацию, когда мы переводим деньги (в доке такой же пример). 👀Что мы делаем: у нас есть ручка (ендпоинт/хэндлер, кому как удобно) которая просто переводит деньги, вот ее код упрощенно сразу команда на sql 💰UPDATE accounts SET balance = balance + 100.00 WHERE id = 1;UPDATE accounts SET balance = balance - 100.00 WHERE id = 2; Проблематика: В 99.99% случаев все будет норм, мы блокируем строку на которую переводим деньги, потом ту с которой списываем - все хорошо. Но если случится конкурентный запрос встречных переводов? (T1: id1 => id2, T2: id2 => id1)🥃🥃Короч, мы переводим деньги друг другу одновременно. Тогда постргрес начнет выполнять операции (см. скрин) и упрется в то, что у нас две строки заблокированы разными транзакциями.Решение: Если сложно - ничего не делай, постгрес сам выберет одну из транзакций и убьет. Но вообще, чтобы такого не случалось, есть хорошая рекомендация от самого постгреса. 🏋️♂️Организуйте блокировки так, чтобы они всегда были в одном порядке (фокус не на действие, а именно на порядок). Тоесть наши две транзакции сначала должны блокировать строку с id=1, а уже потом с id=2 (см. скрин 2)Это простой базовый трюк, который можно применить, но на практике особо никто не парится, так как код становится сложнее читать и пусть PG убьет транзакцию, не критично.Но, на собесе надо уметь такое рассказать. Так что запоминай и в следующий раз обязательно расскажи как решать проблему дедлока.🫡
Оставить комментарий/отзыв