Приведи пример транзакции в реальной жизни
Что проверяют
Умеете ли объяснять ACID на пальцах и видите ли, где аналогия перестаёт работать. Вопрос обманчиво простой: житейский пример расскажут все, а дальше собеседник свернёт на границы транзакции в Spring и уровни изоляции, и там станет видно, работали вы с этим или читали.
Как отвечать
Берите перевод денег между счетами: списание с одного и зачисление на другой обязаны произойти вместе.
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;На этом примере разложите буквы:
- атомарность: изменились обе строки либо ни одной, сбой между ними откатывает всё;
- согласованность: сумма на счетах не поменялась, ограничения таблиц не нарушены;
- изолированность: параллельная операция не увидит состояние, где деньги списаны, но ещё не зачислены;
- долговечность: после подтверждения запись переживёт отключение питания, потому что журнал уже на диске.
Дальше переводите на Java. В Spring границу задаёт @Transactional, откат по умолчанию срабатывает на непроверяемых исключениях, для проверяемых нужен rollbackFor. Вызов транзакционного метода изнутри того же бина идёт мимо прокси, и транзакции не будет вовсе. Внешние действия, письмо или запрос в чужой сервис, откатить нельзя: их выносят за коммит или в обработчик события после фиксации.
Где спотыкаются
Берут пример с покупкой в магазине: корзина, списание с карты, чек. Шаги идут через разные системы, одной транзакцией базы это не накрывается. Там сага с компенсациями: платёж не откатывают, а возвращают отдельной операцией.
Второе: путают согласованность из ACID с согласованностью из теоремы CAP. В первом случае речь про инварианты одной базы, во втором про то, видят ли реплики одно и то же.
Третье: называют четыре буквы, но не могут привязать к уровню изоляции ни одной аномалии. Держите наготове грязное чтение, неповторяемое чтение и фантомы, и какой уровень что запрещает.