Что такое общие причины мертвых блокировок?
Простейшим для вас может быть введение компонента «poll» библиотеки ajax4jsf: https://ajax4jsf.dev.java.net/nonav/documentation/ajax-documentation/entire.html#d0e1955
Это не потребует реконфигурации приложения и больших изменений на странице JSF (добавление компонента a4j: poll добавлено)
Он работал очень хорошо в нескольких моих проектах.
8 ответов
Обновление: Эта недавняя статья MSDN, Инструменты И Методы для Идентификации Проблем Параллелизма , могла бы также представлять интерес
<час>Stephen Toub в мониторе Мертвой блокировки статьи MSDN состояния следующие четыре условия, необходимые, чтобы мертвые блокировки произошли:
-
ограниченное количество А конкретного ресурса. В случае монитора в C# (что Вы используете при использовании ключевого слова блокировки), это ограниченное количество один, так как монитор является блокировкой взаимного исключения (значение, что только один поток может владеть монитором за один раз).
-
способность содержать один ресурс и запросить другого. В C# это сродни соединению одного объекта и затем соединению другого прежде, чем выпустить первую блокировку, например:
lock(a)
{
...
lock(b)
{
...
}
}
-
Никакая возможность вытеснения. В C# это означает, что один поток не может вынудить другой поток выпустить блокировку.
-
А круговое условие ожидания. Это означает, что существует цикл потоков, каждый из которых ожидает рядом с выпуском ресурс, прежде чем он сможет продолжиться.
Он продолжает объяснять, что способ избежать мертвых блокировок состоит в том, чтобы избежать (или банка) условия четыре.
Joe Duffy обсуждает несколько методов для предотвращения и обнаружения мертвых блокировок, включая одно известное как выравнивание блокировки. В выравнивании блокировки блокировки являются присвоенными численными значениями, и потоки должны только получить блокировки, которые имеют более высокие числа, чем блокировки, которые они уже получили. Это предотвращает возможность цикла. Также часто трудно преуспеть в типичном приложении сегодня, и отказ следовать за блокировкой, выравнивающейся на каждом приобретении блокировки, приглашает мертвую блокировку.
Классический сценарий мертвой блокировки является A, фиксатор X и хочет получить блокировку Y, в то время как B является фиксатором Y и хочет получить блокировку X. Так как ни один не может завершить то, что они пытаются сделать, оба закончат тем, что ожидали навсегда (если тайм-ауты не будут использоваться).
В этом случае мертвой блокировки можно избежать, если A и B получают блокировки в том же порядке.
Никакие шаблоны мертвой блокировки к моему знанию (и 12 лет записи в большой степени многопоточных торговых приложений).. Но класс TimedLock очень помог в нахождении мертвых блокировок, которые существуют в коде без крупного, переделывают.
http://www.randomtree.org/eric/techblog/archives/2004/10/multithreading_is_hard.html
в основном, (в dotnet/c#) Вы ищете/заменяете всю свою "блокировку (xxx)" операторы с "использованием TimedLock. Блокировка (xxx)"
, Если мертвая блокировка когда-либо обнаруживается (блокируют не могущий быть полученным в указанном тайм-ауте, значениях по умолчанию к 10 секундам), то исключение выдается. Моя локальная версия также сразу регистрирует stacktrace. Идите по stacktrace (предпочтительно отладочная сборка с номерами строки), и Вы будете сразу видеть то, какие блокировки были сохранены при отказе, и какой он пытался получить.
В dotnet 1.1, в ситуации с мертвой блокировкой, как описано, по стечению обстоятельств все потоки, которые были заблокированы, выдадут исключение одновременно. Таким образом, Вы заставили бы 2 + stacktraces, и вся информация, необходимая решать проблему. (2.0 +, возможно, изменил модель потоков внутренне достаточно, чтобы не быть этим удачным, я не уверен)
Проверка всех таблиц влияния транзакций в том же порядке является ключом к предотвращению наиболее распространенной из мертвых блокировок.
, Например:
Транзакция
UPDATE Table A SET Foo = 'Bar'
UPDATE Table B SET Bar = 'Foo'
транзакция B
UPDATE Table B SET Bar = 'Foo'
UPDATE Table A SET Foo = 'Bar'
Это, чрезвычайно вероятно, приведет к мертвой блокировке как [1 110], Транзакция получает блокировку на Таблице A, , транзакция B получает блокировку на таблице B, поэтому ни один из них не получает блокировку для их второй команды, пока другой не закончился.
Все другие формы мертвых блокировок обычно вызываются посредством использования высокой интенсивности и SQL Server, заходящего в тупик внутренне пока выделенные ресурсы.
Да - мертвые блокировки происходят, когда процессы пытаются получить ресурсы в произвольном порядке. Если все Ваши процессы пытаются получить те же ресурсы в том же порядке, возможности для мертвых блокировок значительно уменьшаются, если не устраненный.
, Конечно, это не всегда легко расположить...
Типичному сценарию не соответствуют планы обновления (таблицы, не всегда обновляемые в том же порядке). Однако весьма обычно иметь мертвые блокировки когда под высоким объемом обработки.
я склонен принимать мертвые блокировки как факт жизни, это произойдет один день, или другой так мне подготовили мой DAL, чтобы обработать и повторить заведенную в тупик операцию.
Наиболее распространенное (согласно моим ненаучным наблюдениям) сценарий мертвой блокировки DB очень просто:
- Два процесса читают что-то (запись DB, например), оба получают коллективную блокировку на связанном ресурсе (обычно страница DB),
- Обе попытки сделать обновление, пытаясь обновить их блокировки до эксклюзивных - вуаля, мертвая блокировка.
Этого можно избежать путем определения пункта "FOR UPDATE" (или подобный, в зависимости от конкретного RDBMS), если чтение должно сопровождаться обновлением. Таким образом, процесс получает монопольную блокировку от запуска, делая вышеупомянутый сценарий невозможным.
Я рекомендую прочитать эту статью Херба Саттера . Он объясняет причины проблем с тупиковой ситуацией и предлагает основу в этой статье для решения этой проблемы.