Сообщений в теме: 6

[wret]

Добрый день!

Может кто высказаться на тему тестирования гонок, блокировок, дедлоков?

Еще Канер в своей книжке по 5 раз (как и обо всем остальном) писал что редко кто такое тестирует правильно и качественно

 

Чтобы не быть многословным приведу пример:

Есть веб-сервис, логика его примерно такая: взять информацию из разных таблиц и засунуть в другую (типичный шлюз интеграции)

Во время выборки на каждую запись в таблице источнике должен устанавливаться лок на апдейт данных

 

Как бы вы проверили, что лок ставится? Многопоточно (посылать запросы на сервис и параллельно пытаться апдейтить таблицу)? Через нагрузку? Ну или разобраться в коде?)

 

Спасибо

 

[wret]

Вот, кстати, практически единственная статья на эту тему

http://msdn.microsof...e/cc546569.aspx

 

Но вопрос открыт, жду ваших идей

Чую доклад на эту тему будет полезен

[Лелик32]

Есть веб-сервис, логика его примерно такая: взять информацию из разных таблиц и засунуть в другую (типичный шлюз интеграции)
Во время выборки на каждую запись в таблице источнике должен устанавливаться лок на апдейт данных
Как бы вы проверили, что лок ставится? Многопоточно (посылать запросы на сервис и параллельно пытаться апдейтить таблицу)? Через нагрузку? Ну или разобраться в коде?)

Это же все делается на уровне БД. Если у вас не самописная БД (что навряд ли), то все эти требования удовлетворяются из "коробки", ибо являются основополагающими понятиями.

[wret]

 

Есть веб-сервис, логика его примерно такая: взять информацию из разных таблиц и засунуть в другую (типичный шлюз интеграции)
Во время выборки на каждую запись в таблице источнике должен устанавливаться лок на апдейт данных
Как бы вы проверили, что лок ставится? Многопоточно (посылать запросы на сервис и параллельно пытаться апдейтить таблицу)? Через нагрузку? Ну или разобраться в коде?)

Это же все делается на уровне БД. Если у вас не самописная БД (что навряд ли), то все эти требования удовлетворяются из "коробки", ибо являются основополагающими понятиями.

 

Пусть на уровне БД (если вы про автоматический лок), в требовании написано: вернуть ошибку 123 если запись заблокирована в данный момент. Как проверить?

 

Смоделируем ситуацию (лок ручной):

Оплата товара (лок на запись с транзакцией), печать на ККМ чека по транзакции. ККМ затупил (бумага кончилась).

Программа решила обновить транзакцию (ей надо записать что ККМ умер), в то время как ККМ лок еще не снял (коннект не успел кильнуться) - креш

 

Ну и вопрос не только про БД был

[neman]

Интересно. Я вижу это так. Два варианта:

1) Есть техническое требование - должен выставляться лок при таких-то условиях. Отлично. Задача для юнит-тестов. Выполняем предусловия, проверяем что запись залочена (имеет соответствующее свойство, возвращает соответствующую ошибку и т.п). 

2) Есть бизнес-требование. Примеры уже описали сами - множество пользователей, специфические сценарии и так далее. Тут мы уже абстрагируемся от терминов многопоточного программирования. Если у нас бизнес-требование "Веб-сервис должен держать 10 000 rpm" - ну ок, имитируем подобную загрузку и следим, что у нас все тип-топ. В голове мы конечно держим, что узкое место - это лок в базе, но проверяем мы конкретное требование.

 

PS: Насчет корректной реализации лока в БД. Отчасти это так, не надо проверять сторонний компонент. Тем не менее, может быть например выставлен некорректный уровень блокировки. Мне с таким довелось сталкиваться при работе с Оракловой базой. В общем автору -- если вы спрашиваете об этом на форуме, то скорее всего не сможете предусмотреть все варианты. Так что лучше отталкиваться от бизнес-требований.

[wret]

Интересно. Я вижу это так. Два варианта:

1) Есть техническое требование - должен выставляться лок при таких-то условиях. Отлично. Задача для юнит-тестов. Выполняем предусловия, проверяем что запись залочена (имеет соответствующее свойство, возвращает соответствующую ошибку и т.п). 

2) Есть бизнес-требование. Примеры уже описали сами - множество пользователей, специфические сценарии и так далее. Тут мы уже абстрагируемся от терминов многопоточного программирования. Если у нас бизнес-требование "Веб-сервис должен держать 10 000 rpm" - ну ок, имитируем подобную загрузку и следим, что у нас все тип-топ. В голове мы конечно держим, что узкое место - это лок в базе, но проверяем мы конкретное требование.

 

PS: Насчет корректной реализации лока в БД. Отчасти это так, не надо проверять сторонний компонент. Тем не менее, может быть например выставлен некорректный уровень блокировки. Мне с таким довелось сталкиваться при работе с Оракловой базой. В общем автору -- если вы спрашиваете об этом на форуме, то скорее всего не сможете предусмотреть все варианты. Так что лучше отталкиваться от бизнес-требований.

Спасибо за мнение

На тему лока при выборке: написал select, забыл написать for update

На тему некорректного уровня блокировки: все кто не особо понимает в БД пишут LOCK ... IN EXCLUSIVE MODE

[wret]

С примером из шапки разобрался без нагрузки, следовало выполнить всего один SQL запрос