PHP PHP · 25 вопросов · ~70 мин · ⏱ Таймер 10:00 · Средний ·

Транзакции и согласованность

Успешный commit ещё не означает правильный бизнес-результат. Вопросы требуют выбрать границы транзакции, учитывать исключения, блокировки и повтор запроса после сбоя или сетевой неопределённости.

Отвечено: 0 из 25

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. Прослеживайте все изменяемые ресурсы и момент, после которого операцию нельзя бездумно повторить. Время — 70 минут.

Вопрос 1 из 25

Когда изменения транзакции фиксируются?

$pdo->beginTransaction();
$orders->create($order);
$pdo->commit();

При каждом fetch После завершения PHP-запроса независимо от вызова commit Перед beginTransaction Сразу после prepare После успешного commit

Вопрос 2 из 25

Что объединять в одну транзакцию?

$pdo->beginTransaction();
$accounts->debit($from, 100);
$accounts->credit($to, 100);
$pdo->commit();

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

Вопрос 3 из 25

Что произойдёт без beginTransaction при обычном автокоммите?

$pdo->exec("UPDATE accounts SET balance = balance - 100 WHERE id = 1");
$pdo->exec("UPDATE accounts SET balance = balance + 100 WHERE id = 2");

PDO откроет одну транзакцию на всю пользовательскую сессию Каждый отдельный statement обычно фиксируется самостоятельно Все запросы автоматически откатятся при завершении PHP-процесса INSERT не выполнится без явного вызова beginTransaction PDO автоматически объединит оба UPDATE, если они идут подряд на одном соединении

Вопрос 4 из 25

Почему commit следует выполнять после всех проверок базы?

Commit удаляет соединение Проверки работают только внутри транзакции Он очищает PHP-переменные После commit можно откатить только последний statement, но не всю операцию После commit откатить эту транзакцию уже нельзя

Вопрос 5 из 25

Что неверно в коде?

$pdo->beginTransaction();
$repo->createOrder($order);
$mailer->sendConfirmation($order);
$pdo->commit();

Commit должен быть до execute Mail автоматически участвует в SQL beginTransaction нельзя вызывать у PDO INSERT обязан быть SELECT Письмо внутри транзакции не откатится вместе с БД

Вопрос 6 из 25

Когда вызывать rollBack?

$pdo->beginTransaction();
try {
    reserveStock($pdo, $orderId);
    debitBalance($pdo, $userId, $amount);
    $pdo->commit();
} catch (Throwable $error) {
    if ($pdo->inTransaction()) {
        $pdo->rollBack();
    }
    throw $error;
}

Вместо prepare При сбое до commit, если транзакция активна До beginTransaction Только при SELECT После каждого успешного commit

Вопрос 7 из 25

Откатит ли rollback отправленный HTTP-запрос платёжному сервису?

$pdo->beginTransaction();
$orders->markPaid($orderId);
$payments->charge($card, 1000);
$pdo->rollBack();

Нет, транзакция базы не управляет внешней системой Да, PDO автоматически отправит компенсирующий HTTP-запрос при rollback Только если внешний сервис вернул статус 200 до отката Да, уровень Serializable включает внешние побочные эффекты Только если база и платёжный сервис вызваны из одного PHP-процесса

Вопрос 8 из 25

Почему важно повторно бросить исключение после rollback?

try {
    $transaction->run($operation);
} catch (Throwable $error) {
    $pdo->rollBack();
    throw $error;
}

Вызывающий уровень должен знать, что операция не завершилась Исключение нужно повторить только для очистки пользовательских cookie Rollback возвращает готовый результат заказа вызывающему уровню После перехвата PHP запрещает выбрасывать то же или обёрнутое исключение Без повторного throw PDO автоматически выполнит commit после rollback

Вопрос 9 из 25

Что делает finally в транзакционной обёртке?

Очищает ресурсы, но commit или rollback выбирают по исходу finally превращает результат SQL в массив для вызывающего кода finally всегда фиксирует транзакцию, даже если try завершился ошибкой finally сам выбирает rollback при наличии любого Throwable Блок finally удаляет таблицы и временные данные текущей транзакции

Вопрос 10 из 25

Какой шаблон корректнее?

$pdo->beginTransaction();
try { $work(); $pdo->commit(); }
catch(Throwable $e){ if($pdo->inTransaction())$pdo->rollBack(); throw $e; }

Сделать commit до вызова операций, которые должны быть атомарными Открыть транзакцию в catch, а commit выполнить безусловно в finally Выполнить rollback после возврата успешного результата из метода Перехватить исключение пустым catch и вернуть обычный результат begin и commit в try; rollback и throw в catch

Вопрос 11 из 25

Что такое потерянное обновление?

$balanceA = 100;
$balanceB = 100;

$afterA = $balanceA - 30;
$afterB = $balanceB - 50;

Дублирование индекса Удаление строки по внешнему ключу Ошибка синтаксиса UPDATE Потеря соединения до SELECT Одна транзакция перезаписывает результат другой

Вопрос 12 из 25

Как атомарно уменьшить остаток, только если товара хватает?

$stmt = $pdo->prepare(
    'UPDATE stock SET amount = amount - :n WHERE id = :id AND amount >= :n'
);
$stmt->execute(['n' => $quantity, 'id' => $productId]);
if ($stmt->rowCount() !== 1) {
    throw new DomainException('Недостаточный остаток');
}

Использовать GET-запрос Условный UPDATE stock=stock-:n ... AND stock>=:n SELECT, sleep, затем UPDATE без условия Считать stock в PHP и довериться Отключить транзакции

Вопрос 13 из 25

Что даёт SELECT ... FOR UPDATE?

Шифрует результат до завершения текущего соединения Работает вне транзакции как долговременный кэш прочитанных строк Сразу обновляет выбранные строки без выражения SET Создаёт постоянный индекс по выбранным условиям WHERE Блокирует выбранные строки до конца транзакции

Вопрос 14 из 25

Зачем выбирать уровень изоляции осознанно?

Serializable всегда быстрее, потому что выполняет транзакции строго по очереди Изоляция влияет только на рендеринг HTML, но не на чтения и записи Уровень изоляции меняет типы PHP-значений, возвращаемых PDO Все уровни дают одинаковые аномалии, различаясь только названием Строже — меньше аномалий, но больше ожиданий и конфликтов

Вопрос 15 из 25

Что такое неповторяемое чтение?

Повторный SELECT той же строки в транзакции видит изменённое значение Запрос невозможно выполнить второй раз Читается другая таблица SELECT возвращает строки в другом порядке без ORDER BY База возвращает дубликаты колонок

Вопрос 16 из 25

Когда retry транзакции уместен?

for ($attempt = 1; $attempt <= 3; $attempt++) {
    try {
        $transaction->run($work);
        break;
    } catch (DeadlockException|SerializationFailure $error) {
        if ($attempt === 3) throw $error;
        usleep(random_int(10_000, 80_000));
    }
}

Для временного deadlock или serialization failure с лимитом Для любого нарушения уникальности, включая постоянный конфликт бизнес-ключа Без ограничения числа попыток при любом классе исключения После ошибки пользовательской валидации с теми же неверными данными После синтаксической ошибки SQL, которая не изменится при повторе

Вопрос 17 из 25

Почему весь блок должен быть идемпотентным для retry?

$transaction->run(function () use ($command): void {
    $orders->createOnce($command->operationId, $command->data);
    $outbox->addOnce($command->operationId, 'OrderCreated');
});

Commit автоматически отменяется сетью Retry меняет типы параметров Внешний эффект или commit могли уже произойти Идемпотентность нужна только GET PDO выполняет каждый statement дважды всегда

Вопрос 18 из 25

Что такое ключ идемпотентности?

Номер процесса PHP Случайный ключ массива на каждом retry Пароль базы SQLSTATE ошибки Уникальный ID команды для распознавания повтора

Вопрос 19 из 25

Почему sleep без случайности при массовых retry вреден?

sleep удаляет транзакцию Без jitter commit невозможен PHP запрещает задержки Клиенты проснутся одновременно и повторят конфликт Случайность делает SQL безопасным от инъекций

Вопрос 20 из 25

Какие ошибки нельзя просто повторять?

Краткий сетевой сбой до известного commit Валидацию, синтаксис и устойчивые нарушения ограничений Serialization failure Временная перегрузка Deadlock

Вопрос 21 из 25

Почему один PDO в тесте не выявляет гонку?

$first = new PDO($dsn, $user, $password);
$second = new PDO($dsn, $user, $password);
$first->beginTransaction();
$second->beginTransaction();

PDO не поддерживает тесты с несколькими экземплярами подключения Одно соединение всегда работает в readonly и не удерживает блокировки Нет независимых параллельных транзакций и блокировок Гонки возможны только между потоками Java, но не между PHP-процессами Тестовая база отключает SQL-конкурентность независимо от числа соединений

Вопрос 22 из 25

Что проверять после искусственного сбоя между двумя UPDATE?

$pdo->beginTransaction();
$accounts->debit($from, 100);
throw new RuntimeException('Сбой между изменениями');
$accounts->credit($to, 100);

Размер журнала и количество записанных диагностических строк HTTP User-Agent запроса, на котором был искусственно вызван сбой Либо оба изменения выполнены, либо ни одного Только текст выброшенного исключения без проверки сохранённых значений Количество PHP-файлов, затронутых транзакционной обёрткой

Вопрос 23 из 25

Как диагностировать deadlock?

Вернуть пользователю полные конкурирующие запросы и параметры Увеличить memory_limit PHP, не анализируя ожидания блокировок Удалить индексы по одному и считать исчезновение ошибки доказательством Отключить журналы базы, чтобы уменьшить нагрузку во время deadlock SQLSTATE, операции, порядок блокировок и ID транзакций

Вопрос 24 из 25

Почему тест rollback должен заново читать данные отдельным запросом?

Отдельный SELECT всегда быстрее чтения уже загруженного объекта После отката стандарт SQL запрещает выполнять SELECT в том же тесте Проверка локального объекта не доказывает состояние базы Rollback изменяет только локальные PHP-массивы, а база остаётся прежней Предметные объекты автоматически синхронизируются с базой после rollback

Вопрос 25 из 25

Какая метрика полезна в эксплуатации?

Размер composer.json и количество пакетов, использующих PDO Только число вызовов echo внутри транзакционных методов Общее количество классов без времени транзакций и конфликтов Длина сессионной cookie во время конкурирующей операции Retry, deadlock, длительность и ожидание блокировок

Ответьте на все 25 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу