Уровень изоляции транзакций

«Учебный остаток равен 1. Транзакции A и B обе хотят списать 1; допустим только один подтверждённый заказ». Попросите два варианта для вашей СУБД и последовательность действий. В проверке важны количество успешных операций и конечный остаток. Отсутствие исключений не является критерием успеха: обе транзакции могут завершиться формально корректно и нарушить бизнес-правило продажи.

Две операции способны принять решение по одному старому значению. Если затем каждая записывает собственный расчёт, итог может потерять изменение или допустить лишний заказ. Попросите вариант, где условие проверяется при изменении, либо блокируется нужный объект. Конкретная семантика зависит от уровня изоляции и СУБД, поэтому общая фраза «всё внутри транзакции» не объясняет правильность выбранного решения.

Нет, при обнаруженном конфликте приложение может получить отказ, требующий повторения транзакции. Повтор должен заново получить нужные данные и не дублировать внешние побочные эффекты. Попросите определить границу повторяемой операции и предел попыток. Для одного остатка точечное условное изменение может быть проще, но для более сложного инварианта нужно отдельно проверить, охватывает ли оно все связанные строки.

Используйте два независимых соединения и управляемые точки ожидания, которые задают нужное чередование. Обычный последовательный тест не создаёт опасное окно. Попросите проверку финальных данных после завершения обеих операций, включая заказы и остаток. Енотик подготовит сценарий, но не выполняет его на вашей базе; воспроизведение и устойчивость исправления подтверждаются тестом на той же СУБД и настройках изоляции.