Транзакции и целостность данных в Rails — бесплатный тест онлайн

Вопрос 1 из 25

Разберите выражения по порядку. Как завершится фрагмент из раздела «Границы транзакции»? Выберите связку, в которой верны и основной вывод, и его обоснование.

# Проследите выполнение и выберите точный результат.
ApplicationRecord.transaction do
  debit.update!(balance: debit.balance - 10)
  credit.update!(balance: credit.balance + 10)
end

Обе записи в одной транзакции фиксируются вместе либо откатываются при исключении `save!`. Это объясняется тем, что транзакция базы охватывает только операции того же соединения/базы; HTTP-вызов, письмо или другая база не откатываются вместе с ней. Обе записи в одной транзакции фиксируются вместе либо откатываются при исключении `save!`. Это объясняется тем, что `lock`/`with_lock` используют блокировку строки до конца транзакции и позволяют сериализовать конкурентное изменение одной записи. Обе записи в одной транзакции фиксируются вместе либо откатываются при исключении `save!`. Это объясняется тем, что тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Это объясняется тем, что транзакция базы охватывает только операции того же соединения/базы; HTTP-вызов, письмо или другая база не откатываются вместе с ней. CHECK не позволяет сохранить отрицательный баланс даже при update_all или прямом SQL. Это объясняется тем, что транзакция базы охватывает только операции того же соединения/базы; HTTP-вызов, письмо или другая база не откатываются вместе с ней.

Вопрос 2 из 25

Как следует прочитать результат показанного примера «Блокировки»? Правильным считается только полностью согласованное утверждение.

# Проследите выполнение и выберите точный результат.
account.with_lock do
  raise 'insufficient' if account.balance < 10
  account.update!(balance: account.balance - 10)
end

Два конкурентных списания не могут одновременно прочитать один старый баланс после захвата `with_lock`. Причина такого результата: повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Два потока с отдельными соединениями проверяют, что только одно списание проходит при ограниченном балансе. Причина такого результата: `lock`/`with_lock` используют блокировку строки до конца транзакции и позволяют сериализовать конкурентное изменение одной записи. Два конкурентных списания не могут одновременно прочитать один старый баланс после захвата `with_lock`. Причина такого результата: транзакция базы охватывает только операции того же соединения/базы; HTTP-вызов, письмо или другая база не откатываются вместе с ней. Уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Причина такого результата: `lock`/`with_lock` используют блокировку строки до конца транзакции и позволяют сериализовать конкурентное изменение одной записи. Два конкурентных списания не могут одновременно прочитать один старый баланс после захвата `with_lock`. Причина такого результата: `lock`/`with_lock` используют блокировку строки до конца транзакции и позволяют сериализовать конкурентное изменение одной записи.

Вопрос 3 из 25

Какой вариант верно описывает состояние объектов после выполнения кода «Повтор операции»? Оценивайте ответ целиком: обе части утверждения должны быть точными.

# Проследите выполнение и выберите точный результат.
Transfer.transaction do
  transfer = Transfer.find_or_initialize_by(request_id: request_id)
  transfer.amount ||= amount
  transfer.save!
end
# unique index on transfers.request_id

Уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Такой итог следует из правила: повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Два потока с отдельными соединениями проверяют, что только одно списание проходит при ограниченном балансе. Такой итог следует из правила: повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Такой итог следует из правила: тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Такой итог следует из правила: инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Два конкурентных списания не могут одновременно прочитать один старый баланс после захвата `with_lock`. Такой итог следует из правила: повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию.

Вопрос 4 из 25

Что покажет выполнение этого фрагмента из раздела «Согласованность»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.

# Проследите выполнение и выберите точный результат.
# Миграция PostgreSQL
add_check_constraint :accounts,
  'balance >= 0',
  name: 'accounts_balance_nonnegative'

# Модель может добавить понятное сообщение пользователю.

Обе записи в одной транзакции фиксируются вместе либо откатываются при исключении `save!`. Механизм результата таков: инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. CHECK не позволяет сохранить отрицательный баланс даже при update_all или прямом SQL. Механизм результата таков: инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Механизм результата таков: инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. CHECK не позволяет сохранить отрицательный баланс даже при update_all или прямом SQL. Механизм результата таков: повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. CHECK не позволяет сохранить отрицательный баланс даже при update_all или прямом SQL. Механизм результата таков: тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit.

Вопрос 5 из 25

Разберите выражения по порядку. Как завершится фрагмент из раздела «Тестовый сценарий»? Оценивайте ответ целиком: обе части утверждения должны быть точными.

# Проследите выполнение и выберите точный результат.
threads = 2.times.map do
  Thread.new do
    ActiveRecord::Base.connection_pool.with_connection do
      Account.find(account.id).withdraw!(10)
    end
  end
end
threads.each(&:join)

Два потока с отдельными соединениями проверяют, что только одно списание проходит при ограниченном балансе. Наблюдение согласуется с тем, что повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Наблюдение согласуется с тем, что тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Два потока с отдельными соединениями проверяют, что только одно списание проходит при ограниченном балансе. Наблюдение согласуется с тем, что тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Два конкурентных списания не могут одновременно прочитать один старый баланс после захвата `with_lock`. Наблюдение согласуется с тем, что тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Два потока с отдельными соединениями проверяют, что только одно списание проходит при ограниченном балансе. Наблюдение согласуется с тем, что инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё.

Вопрос 6 из 25

Где в показанном решении «Границы транзакции» скрыт дефект, который проявится не на каждом входе? Проверьте обе половины ответа: частично верный вариант остаётся неверным.

# Обычный запуск проходит. Найдите скрытый риск.
ApplicationRecord.transaction do
  debit.update!(balance: debit.balance - 10)
  credit.update!(balance: credit.balance + 10)
end

Слепой retry всего блока с `create!` дублирует запись, если клиент не получил ответ после успешной фиксации. Причина — транзакция базы охватывает только операции того же соединения/базы; HTTP-вызов, письмо или другая база не откатываются вместе с ней. Внешний API, вызванный внутри транзакции, может успешно принять команду, а локальная база затем откатится. Причина — инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Внешний API, вызванный внутри транзакции, может успешно принять команду, а локальная база затем откатится. Причина — `lock`/`with_lock` используют блокировку строки до конца транзакции и позволяют сериализовать конкурентное изменение одной записи. Callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. Причина — транзакция базы охватывает только операции того же соединения/базы; HTTP-вызов, письмо или другая база не откатываются вместе с ней. Внешний API, вызванный внутри транзакции, может успешно принять команду, а локальная база затем откатится. Причина — транзакция базы охватывает только операции того же соединения/базы; HTTP-вызов, письмо или другая база не откатываются вместе с ней.

Вопрос 7 из 25

Почему успешный пример ещё не доказывает надёжность решения «Блокировки»? Оценивайте ответ целиком: обе части утверждения должны быть точными.

# Обычный запуск проходит. Найдите скрытый риск.
account.with_lock do
  raise 'insufficient' if account.balance < 10
  account.update!(balance: account.balance - 10)
end

Один последовательный пример не обнаруживает lost update, а общий connection между потоками не моделирует рабочую конкуренцию. Этот риск связан с тем, что `lock`/`with_lock` используют блокировку строки до конца транзакции и позволяют сериализовать конкурентное изменение одной записи. Разный порядок блокировки нескольких строк создаёт взаимную блокировку; удержание блокировки во время сети увеличивает ожидания. Этот риск связан с тем, что `lock`/`with_lock` используют блокировку строки до конца транзакции и позволяют сериализовать конкурентное изменение одной записи. Разный порядок блокировки нескольких строк создаёт взаимную блокировку; удержание блокировки во время сети увеличивает ожидания. Этот риск связан с тем, что тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. Этот риск связан с тем, что `lock`/`with_lock` используют блокировку строки до конца транзакции и позволяют сериализовать конкурентное изменение одной записи. Разный порядок блокировки нескольких строк создаёт взаимную блокировку; удержание блокировки во время сети увеличивает ожидания. Этот риск связан с тем, что транзакция базы охватывает только операции того же соединения/базы; HTTP-вызов, письмо или другая база не откатываются вместе с ней.

Вопрос 8 из 25

Почему успешный пример ещё не доказывает надёжность решения «Повтор операции»? Верный вариант не содержит частично правильной подмены причины или следствия.

# Обычный запуск проходит. Найдите скрытый риск.
Transfer.transaction do
  transfer = Transfer.find_or_initialize_by(request_id: request_id)
  transfer.amount ||= amount
  transfer.save!
end
# unique index on transfers.request_id

Callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. Уязвимое место возникает потому, что повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Слепой retry всего блока с `create!` дублирует запись, если клиент не получил ответ после успешной фиксации. Уязвимое место возникает потому, что повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Слепой retry всего блока с `create!` дублирует запись, если клиент не получил ответ после успешной фиксации. Уязвимое место возникает потому, что тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Слепой retry всего блока с `create!` дублирует запись, если клиент не получил ответ после успешной фиксации. Уязвимое место возникает потому, что инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Внешний API, вызванный внутри транзакции, может успешно принять команду, а локальная база затем откатится. Уязвимое место возникает потому, что повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию.

Вопрос 9 из 25

Какое скрытое условие делает фрагмент «Согласованность» хрупким? Правильным считается только полностью согласованное утверждение.

# Обычный запуск проходит. Найдите скрытый риск.
# Миграция PostgreSQL
add_check_constraint :accounts,
  'balance >= 0',
  name: 'accounts_balance_nonnegative'

# Модель может добавить понятное сообщение пользователю.

Callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. К такому сбою приводит правило: инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Слепой retry всего блока с `create!` дублирует запись, если клиент не получил ответ после успешной фиксации. К такому сбою приводит правило: инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Внешний API, вызванный внутри транзакции, может успешно принять команду, а локальная база затем откатится. К такому сбою приводит правило: инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. К такому сбою приводит правило: тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. К такому сбою приводит правило: повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию.

Вопрос 10 из 25

Обычный сценарий проходит. Какой риск остаётся в теме «Тестовый сценарий»? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.

# Обычный запуск проходит. Найдите скрытый риск.
threads = 2.times.map do
  Thread.new do
    ActiveRecord::Base.connection_pool.with_connection do
      Account.find(account.id).withdraw!(10)
    end
  end
end
threads.each(&:join)

Callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. Источник риска: тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Один последовательный пример не обнаруживает lost update, а общий connection между потоками не моделирует рабочую конкуренцию. Источник риска: повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Один последовательный пример не обнаруживает lost update, а общий connection между потоками не моделирует рабочую конкуренцию. Источник риска: инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Один последовательный пример не обнаруживает lost update, а общий connection между потоками не моделирует рабочую конкуренцию. Источник риска: тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Разный порядок блокировки нескольких строк создаёт взаимную блокировку; удержание блокировки во время сети увеличивает ожидания. Источник риска: тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit.

Вопрос 11 из 25

Какой контракт нужно помнить при ревью кода по теме «Границы транзакции»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.

Транзакция базы охватывает только операции того же соединения/базы; HTTP-вызов, письмо или другая база не откатываются вместе с ней. Поэтому обе записи в одной транзакции фиксируются вместе либо откатываются при исключении `save!`. Транзакция базы охватывает только операции того же соединения/базы; HTTP-вызов, письмо или другая база не откатываются вместе с ней. Поэтому cHECK не позволяет сохранить отрицательный баланс даже при update_all или прямом SQL. Транзакция базы охватывает только операции того же соединения/базы; HTTP-вызов, письмо или другая база не откатываются вместе с ней. Поэтому уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Поэтому обе записи в одной транзакции фиксируются вместе либо откатываются при исключении `save!`. `lock`/`with_lock` используют блокировку строки до конца транзакции и позволяют сериализовать конкурентное изменение одной записи. Поэтому обе записи в одной транзакции фиксируются вместе либо откатываются при исключении `save!`.

Вопрос 12 из 25

Какой принцип темы «Блокировки» переносится на другие примеры того же типа? Оценивайте ответ целиком: обе части утверждения должны быть точными.

`lock`/`with_lock` используют блокировку строки до конца транзакции и позволяют сериализовать конкурентное изменение одной записи. Из этого следует, что уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Из этого следует, что два конкурентных списания не могут одновременно прочитать один старый баланс после захвата `with_lock`. `lock`/`with_lock` используют блокировку строки до конца транзакции и позволяют сериализовать конкурентное изменение одной записи. Из этого следует, что два конкурентных списания не могут одновременно прочитать один старый баланс после захвата `with_lock`. `lock`/`with_lock` используют блокировку строки до конца транзакции и позволяют сериализовать конкурентное изменение одной записи. Из этого следует, что два потока с отдельными соединениями проверяют, что только одно списание проходит при ограниченном балансе. Транзакция базы охватывает только операции того же соединения/базы; HTTP-вызов, письмо или другая база не откатываются вместе с ней. Из этого следует, что два конкурентных списания не могут одновременно прочитать один старый баланс после захвата `with_lock`.

Вопрос 13 из 25

Какой контракт нужно помнить при ревью кода по теме «Повтор операции»? Правильным считается только полностью согласованное утверждение.

Повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Наблюдаемое следствие: уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Наблюдаемое следствие: два потока с отдельными соединениями проверяют, что только одно списание проходит при ограниченном балансе. Тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Наблюдаемое следствие: уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Наблюдаемое следствие: уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Наблюдаемое следствие: два конкурентных списания не могут одновременно прочитать один старый баланс после захвата `with_lock`.

Вопрос 14 из 25

Какое правило остаётся верным, даже если вход и порядок вызовов изменятся, в теме «Согласованность»? Смотрите на всю причинную связку, а не только на знакомую формулировку.

Тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Именно поэтому cHECK не позволяет сохранить отрицательный баланс даже при update_all или прямом SQL. Инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Именно поэтому уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Именно поэтому cHECK не позволяет сохранить отрицательный баланс даже при update_all или прямом SQL. Повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Именно поэтому cHECK не позволяет сохранить отрицательный баланс даже при update_all или прямом SQL. Инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Именно поэтому обе записи в одной транзакции фиксируются вместе либо откатываются при исключении `save!`.

Вопрос 15 из 25

Какое правило Ruby или Rails объясняет поведение в теме «Тестовый сценарий»? Верный вариант не содержит частично правильной подмены причины или следствия.

Тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Это правило даёт такой результат: уникальный ключ операции позволяет повторному запросу найти прежний перевод вместо создания второго. Тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Это правило даёт такой результат: два конкурентных списания не могут одновременно прочитать один старый баланс после захвата `with_lock`. Тест транзакционной логики должен воспроизводить конкуренцию и реальную фиксацию; транзакционная обёртка самого теста может скрывать after_commit. Это правило даёт такой результат: два потока с отдельными соединениями проверяют, что только одно списание проходит при ограниченном балансе. Инвариант должен быть выражен на самом низком надёжном уровне: ограничения базы защищают от всех путей записи, модель — только от путей через неё. Это правило даёт такой результат: два потока с отдельными соединениями проверяют, что только одно списание проходит при ограниченном балансе. Повтор транзакции безопасен только при идемпотентных локальных и внешних действиях; исключение после commit может скрыть уже выполненную операцию. Это правило даёт такой результат: два потока с отдельными соединениями проверяют, что только одно списание проходит при ограниченном балансе.

Вопрос 16 из 25

Какое изменение устраняет причину проблемы в теме «Границы транзакции», а не маскирует симптом? Правильным считается только полностью согласованное утверждение.

# Выберите изменение, которое исправляет причину.
ApplicationRecord.transaction do
  debit.update!(balance: debit.balance - 10)
  credit.update!(balance: credit.balance + 10)
end

Дублировать критичный инвариант ограничением базы и удобной прикладной валидацией, согласовав их формулировки. Так закрывается риск: внешний API, вызванный внутри транзакции, может успешно принять команду, а локальная база затем откатится. Держать транзакцию короткой, а внешний эффект координировать через outbox/saga и идемпотентную доставку. Так закрывается риск: внешний API, вызванный внутри транзакции, может успешно принять команду, а локальная база затем откатится. Держать транзакцию короткой, а внешний эффект координировать через outbox/saga и идемпотентную доставку. Так закрывается риск: callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. Блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции. Так закрывается риск: внешний API, вызванный внутри транзакции, может успешно принять команду, а локальная база затем откатится. Держать транзакцию короткой, а внешний эффект координировать через outbox/saga и идемпотентную доставку. Так закрывается риск: слепой retry всего блока с `create!` дублирует запись, если клиент не получил ответ после успешной фиксации.

Вопрос 17 из 25

Что следует изменить в решении «Блокировки», чтобы закрыть исходный риск? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.

# Выберите изменение, которое исправляет причину.
account.with_lock do
  raise 'insufficient' if account.balance < 10
  account.update!(balance: account.balance - 10)
end

Блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции. Это изменение устраняет проблему: разный порядок блокировки нескольких строк создаёт взаимную блокировку; удержание блокировки во время сети увеличивает ожидания. Дублировать критичный инвариант ограничением базы и удобной прикладной валидацией, согласовав их формулировки. Это изменение устраняет проблему: разный порядок блокировки нескольких строк создаёт взаимную блокировку; удержание блокировки во время сети увеличивает ожидания. Блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции. Это изменение устраняет проблему: один последовательный пример не обнаруживает lost update, а общий connection между потоками не моделирует рабочую конкуренцию. Блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции. Это изменение устраняет проблему: callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. Держать транзакцию короткой, а внешний эффект координировать через outbox/saga и идемпотентную доставку. Это изменение устраняет проблему: разный порядок блокировки нескольких строк создаёт взаимную блокировку; удержание блокировки во время сети увеличивает ожидания.

Вопрос 18 из 25

Какое исправление уменьшает риск, не скрывая исходное поведение «Повтор операции»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.

# Выберите изменение, которое исправляет причину.
Transfer.transaction do
  transfer = Transfer.find_or_initialize_by(request_id: request_id)
  transfer.amount ||= amount
  transfer.save!
end
# unique index on transfers.request_id

Требовать идемпотентный ключ на границе команды и закреплять его уникальным ограничением базы. Такая правка нужна из-за риска: callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. Держать транзакцию короткой, а внешний эффект координировать через outbox/saga и идемпотентную доставку. Такая правка нужна из-за риска: слепой retry всего блока с `create!` дублирует запись, если клиент не получил ответ после успешной фиксации. Блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции. Такая правка нужна из-за риска: слепой retry всего блока с `create!` дублирует запись, если клиент не получил ответ после успешной фиксации. Требовать идемпотентный ключ на границе команды и закреплять его уникальным ограничением базы. Такая правка нужна из-за риска: слепой retry всего блока с `create!` дублирует запись, если клиент не получил ответ после успешной фиксации. Требовать идемпотентный ключ на границе команды и закреплять его уникальным ограничением базы. Такая правка нужна из-за риска: внешний API, вызванный внутри транзакции, может успешно принять команду, а локальная база затем откатится.

Вопрос 19 из 25

Какое действие добавляет недостающую гарантию в блоке «Согласованность»? Смотрите на всю причинную связку, а не только на знакомую формулировку.

# Выберите изменение, которое исправляет причину.
# Миграция PostgreSQL
add_check_constraint :accounts,
  'balance >= 0',
  name: 'accounts_balance_nonnegative'

# Модель может добавить понятное сообщение пользователю.

Держать транзакцию короткой, а внешний эффект координировать через outbox/saga и идемпотентную доставку. Решение адресует следующий дефект: callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. Блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции. Решение адресует следующий дефект: callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. Дублировать критичный инвариант ограничением базы и удобной прикладной валидацией, согласовав их формулировки. Решение адресует следующий дефект: внешний API, вызванный внутри транзакции, может успешно принять команду, а локальная база затем откатится. Дублировать критичный инвариант ограничением базы и удобной прикладной валидацией, согласовав их формулировки. Решение адресует следующий дефект: callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. Дублировать критичный инвариант ограничением базы и удобной прикладной валидацией, согласовав их формулировки. Решение адресует следующий дефект: слепой retry всего блока с `create!` дублирует запись, если клиент не получил ответ после успешной фиксации.

Вопрос 20 из 25

Какой рефакторинг делает контракт блока «Тестовый сценарий» явным и проверяемым? В правильном ответе вторая часть действительно объясняет или проверяет первую.

Создать детерминированный барьер между чтением и записью и проверять конечный инвариант, а не конкретный порядок потоков. Именно эта мера закрывает риск: callback-валидация проходит на снимке данных и может проиграть гонку; `update_all` к тому же обходит callbacks. Блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции. Именно эта мера закрывает риск: один последовательный пример не обнаруживает lost update, а общий connection между потоками не моделирует рабочую конкуренцию. Создать детерминированный барьер между чтением и записью и проверять конечный инвариант, а не конкретный порядок потоков. Именно эта мера закрывает риск: разный порядок блокировки нескольких строк создаёт взаимную блокировку; удержание блокировки во время сети увеличивает ожидания. Создать детерминированный барьер между чтением и записью и проверять конечный инвариант, а не конкретный порядок потоков. Именно эта мера закрывает риск: один последовательный пример не обнаруживает lost update, а общий connection между потоками не моделирует рабочую конкуренцию. Дублировать критичный инвариант ограничением базы и удобной прикладной валидацией, согласовав их формулировки. Именно эта мера закрывает риск: один последовательный пример не обнаруживает lost update, а общий connection между потоками не моделирует рабочую конкуренцию.

Вопрос 21 из 25

Какой сценарий должен падать на старой реализации и проходить после исправления «Границы транзакции»? Верный вариант не содержит частично правильной подмены причины или следствия.

Проверить deadlock/timeout как ожидаемый временный исход и повторять всю транзакцию, а не только последнюю запись. Этот сценарий проверяет исправление: держать транзакцию короткой, а внешний эффект координировать через outbox/saga и идемпотентную доставку. Проверить, что обе модели действительно используют одно соединение; транзакция Active Record не распределена автоматически. Этот сценарий проверяет исправление: держать транзакцию короткой, а внешний эффект координировать через outbox/saga и идемпотентную доставку. Проверить, что обе модели действительно используют одно соединение; транзакция Active Record не распределена автоматически. Этот сценарий проверяет исправление: дублировать критичный инвариант ограничением базы и удобной прикладной валидацией, согласовав их формулировки. Проверить адаптер и уровень изоляции, используемые в рабочей базе: SQLite-тест не заменяет поведение PostgreSQL. Этот сценарий проверяет исправление: держать транзакцию короткой, а внешний эффект координировать через outbox/saga и идемпотентную доставку. Проверить, что обе модели действительно используют одно соединение; транзакция Active Record не распределена автоматически. Этот сценарий проверяет исправление: блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции.

Вопрос 22 из 25

Чем дополнить базовый тест, чтобы проверить ограничение темы «Блокировки»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.

Проверить deadlock/timeout как ожидаемый временный исход и повторять всю транзакцию, а не только последнюю запись. Так проверяется решение: блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции. Проверить deadlock/timeout как ожидаемый временный исход и повторять всю транзакцию, а не только последнюю запись. Так проверяется решение: держать транзакцию короткой, а внешний эффект координировать через outbox/saga и идемпотентную доставку. Проверить адаптер и уровень изоляции, используемые в рабочей базе: SQLite-тест не заменяет поведение PostgreSQL. Так проверяется решение: блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции. Проверить deadlock/timeout как ожидаемый временный исход и повторять всю транзакцию, а не только последнюю запись. Так проверяется решение: дублировать критичный инвариант ограничением базы и удобной прикладной валидацией, согласовав их формулировки. Проверить существующие плохие данные перед включением ограничения, иначе миграция остановится в рабочей среде. Так проверяется решение: блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции.

Вопрос 23 из 25

Какой граничный сценарий лучше всего проверит решение по теме «Повтор операции»? Проверьте обе половины ответа: частично верный вариант остаётся неверным.

Проверить повтор с тем же ключом, но другим amount: это конфликт контракта, а не успешная идемпотентность. Проверка относится к изменению: блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции. Проверить повтор с тем же ключом, но другим amount: это конфликт контракта, а не успешная идемпотентность. Проверка относится к изменению: держать транзакцию короткой, а внешний эффект координировать через outbox/saga и идемпотентную доставку. Проверить существующие плохие данные перед включением ограничения, иначе миграция остановится в рабочей среде. Проверка относится к изменению: требовать идемпотентный ключ на границе команды и закреплять его уникальным ограничением базы. Проверить адаптер и уровень изоляции, используемые в рабочей базе: SQLite-тест не заменяет поведение PostgreSQL. Проверка относится к изменению: требовать идемпотентный ключ на границе команды и закреплять его уникальным ограничением базы. Проверить повтор с тем же ключом, но другим amount: это конфликт контракта, а не успешная идемпотентность. Проверка относится к изменению: требовать идемпотентный ключ на границе команды и закреплять его уникальным ограничением базы.

Вопрос 24 из 25

Какую границу контракта «Согласованность» нужно закрепить отдельным тестом? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.

Проверить существующие плохие данные перед включением ограничения, иначе миграция остановится в рабочей среде. Сценарий подтверждает надёжность решения: блокировать минимальный набор строк в стабильном порядке и не выполнять внутри медленные внешние операции. Проверить существующие плохие данные перед включением ограничения, иначе миграция остановится в рабочей среде. Сценарий подтверждает надёжность решения: дублировать критичный инвариант ограничением базы и удобной прикладной валидацией, согласовав их формулировки. Проверить существующие плохие данные перед включением ограничения, иначе миграция остановится в рабочей среде. Сценарий подтверждает надёжность решения: держать транзакцию короткой, а внешний эффект координировать через outbox/saga и идемпотентную доставку. Проверить адаптер и уровень изоляции, используемые в рабочей базе: SQLite-тест не заменяет поведение PostgreSQL. Сценарий подтверждает надёжность решения: дублировать критичный инвариант ограничением базы и удобной прикладной валидацией, согласовав их формулировки. Проверить deadlock/timeout как ожидаемый временный исход и повторять всю транзакцию, а не только последнюю запись. Сценарий подтверждает надёжность решения: дублировать критичный инвариант ограничением базы и удобной прикладной валидацией, согласовав их формулировки.

Вопрос 25 из 25

Какой сценарий проверит не только результат, но и побочный эффект решения «Тестовый сценарий»? Выберите связку, в которой верны и основной вывод, и его обоснование.

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