Как вы тестируете условия гонки в базе данных?

30

Я пытаюсь написать код базы данных, чтобы убедиться, что он не зависит от условий гонки, чтобы убедиться, что я заблокировал правильные строки или таблицы. Но я часто задаюсь вопросом: правильный ли мой код? Можно ли заставить какие-либо существующие расы проявить себя? Я хочу быть уверен, что если они произойдут в производственной среде, мое приложение будет работать правильно.

Я обычно точно знаю, какой параллельный запрос может вызвать проблему, но я не знаю, как заставить их запускаться одновременно, чтобы увидеть, происходит ли правильное поведение (например, я использовал правильный тип блокировки), что правильные ошибки брошенный и т. д.

Примечание: я использую PostgreSQL и Perl, поэтому, если на этот вопрос нельзя дать общий ответ, его, вероятно, следует пометить заново.

Обновление: я бы предпочел, чтобы решение было программным. Таким образом, я могу написать автоматизированные тесты, чтобы убедиться, что нет регрессий.

concurrency testing xenoterracide
источник
Под «состоянием гонки» вы подразумеваете «тупик»?
Гай
2
@ Гай ... нет, хотя я верю, что это один из возможных результатов некоторых условий гонки
ксенотеррацид
Условия гонки @Gaius в базе данных - это удаление таблицы перед ее созданием или обновление строки перед ее вставкой. Вообще, я бы предположил, что он обрабатывается логикой приложения вне самой базы данных.
Марк Д
обновить строку до того, как она была вставлена? это не вызовет проблемы с БД. никакое условие гонки не будет похоже на выбор строки и ее обновление, но если другой пользователь обновит его после получения строки, но до обработки вашего обновления.
ксенотеррацид
1
@MarkD - Нет. Существует много типов состояний гонки, которые возникают из-за неправильной инкапсуляции атомарной единицы работы в вашей базе данных. Вот пример. Помните, что «состояние гонки или опасность гонки - это ошибка в электронной системе или процессе, из-за которой выходные данные или результат процесса неожиданно и критически зависят от последовательности или времени других событий ». ( источник )
Ник Чаммас

Ответы:

11

Я делаю это все время с моими модулями T-SQL.

По сути, все, что вам нужно сделать, это запустить ваши модули из двух или более соединений в цикле в течение пары минут . Как правило, все потенциальные проблемы обнаруживаются в течение нескольких минут, при условии, что у вас есть блок SQL Server с достойными процессорами.

Я написал несколько примеров здесь и здесь .

Аляска
источник
4

Я обычно работаю с инструментом командной строки СУБД, просто запустив 2 (или более) экземпляра CLI. Затем вы можете воспроизвести один за другим и в виде гонки (которая будет выглядеть как action-RPG) SQL-операторов, отправляемых вашим прикладным уровнем. Вы должны поэкспериментировать / почувствовать работу систем блокировки в действии, так как ваш CLI немного «зависнет», ожидая снятия блокировок с других CLI.

Если это звучит как грязь, не стесняйтесь говорить об этом ;-)

Julien
источник
не могли бы вы привести пошаговый пример? и можно ли написать программные тесты, чтобы сделать то же самое?
ксенотеррацид
1

Условия гонки требуют многократного выполнения потока, поэтому для модульного тестирования вам понадобится запустить один или несколько потоков. В Oracle я бы использовал DBMS_Scheduler для запуска процесса для симуляции второго пользователя. Если в PostgreSQL / Perl есть способ инициировать второй процесс программно, то вы должны сделать что-то вроде этого:

Процесс 1 Процесс 2

Начать процесс 2. >>                            
Задержка, чтобы позволить 2 сделать свою работу. 
, Блокировка строк или изменение данных.
, Задержка, чтобы позволить 1 сделать свою работу.
Попытка заблокировать строки или изменить данные. ,
Убедитесь, что сделано правильное обращение. ,
Окончание. ,
                                                Окончание.

Хорошо видеть размышления о том, как справляться с условиями гонки и, что более важно, как их тестировать.

Ли Риффель
источник
Я бы не стал описывать такие тесты как юнит-тесты, потому что юнит-тесты должны каждый раз выполняться одинаково. Расовые условия терпят неудачу вовлекают процессы с перерывами, не совсем одинаково каждый раз.
AK
@AlexKuznetsov Вы правы в том, что неожиданные условия гонки могут периодически показывать себя, однако ОП ссылается на ожидаемые условия, которые, по его мнению, должен обрабатывать код. Эти конкретные условия могут быть точно воспроизведены, а обработка проверена с помощью модульного теста.
Ли Риффель
-2

Пока вы блокируете ряды, вы не должны попадать в состояние гонки, поскольку это обычно происходит, когда нет блокировки.

Но вы можете зайти в тупик, если один вопрос заблокирует ваш вопрос слишком долго.

Это трудно проверить, так как время для запросов может измениться при увеличении базы данных.

Запросы, которые хорошо работают с 100 000 строк тестовых данных, уходят с графика с 10 000 000 строк.

Этот тип проблемы может быть очень трудно найти заранее, но у многих БД есть какой-то метод выявления медленных запросов.

Используя это правило, вы сможете перехватывать любые запросы, которые могут вызвать проблемы, с достаточным предупреждением.

Если вы делаете блокировку самостоятельно, это другая история, но там я не могу помочь.

Ник Чаммас
источник
@darioo lol Я подумал, что, может быть, wn - это аббревиатура для чего-то ... idk, что бы он имел в виду под "сделать блокировку самостоятельно". Если он имеет в виду не с помощью ORM, я проверил код, который выводит мой ORM, но он определенно не выполняет блокировка справа. Это одна из причин, по которой я хотел бы проверить сценарий потенциальной гонки.
ксенотеррацид
Да, я имел в виду собственный, и обычно драйвер базы данных обрабатывает блокировку, строку, таблицу или, возможно, поле, но я просто открываю возможность того, что вы используете какую-то БД, которая не обрабатывает блокировку;)
... Я почти уверен, что если у меня будет транзакция с несколькими операторами, моя БД не будет знать, какие строки автоматически блокировать ... таких вещей, как select for updateесли бы они не существовали ...
xenoterracide