deadlock'и при обрывах коннекта
Модераторы: kdv, Alexey Kovyazin
Re: deadlock'и при обрывах коннекта
значит покопался я со всем этим, и картина счас следующая: на всех машинах периодически вылетает "lock conflict on no wait transaction deadlock update conflicts with concurrent update concurrent transaction number is [integer]", в логе птицы ерроры 10054 и 10061. Однозначно определить связь ни со сбоями сетки, ни с действиями операторов не удалось. Теоретически дедлоков быть не должно, но ясен пень что теория с практикой разошлась. Вопрос номер раз - как определить связаны ли эти дедлоки с логикой проги или же с работой сети?
з.ы. транзакция nowait read_committed rec_version
з.ы. транзакция nowait read_committed rec_version
Re:
Ну, отлупить кого-то - это всегда приятно. Но деврейсы просто играют ту музыку, за которую платят деньги. По воплям трудящих. Но отлупить - это я всегда за...kdv писал(а):А деврейсов лупить надо за исправление дефолта.
Re: deadlock'и при обрывах коннекта
Мировая статистика говорит о том, что на 1000 конфликтов из-за логики приходится 1 из-за сети...vik писал(а):Вопрос номер раз - как определить связаны ли эти дедлоки с логикой проги или же с работой сети?
Re: deadlock'и при обрывах коннекта
Сча наверно бить будут, но все таки рискну спросить ) я перекопал кучу вариантов, но так и не смог определить где именно этот дедлок вылетает. Можете подкинуть идеи как найти кусок, который приводит к возникновению дедлоков?
Re: deadlock'и при обрывах коннекта
Код: Выделить всё
как найти кусок, который приводит к возникновению дедлоков?
http://www.ibase.ru/devinfo/mga.htm
Re: deadlock'и при обрывах коннекта
Я знаю как они возникают и как их устранить. Проблема в том, что я не могу найти операцию в клиенте, при которой этот дедлок вылетает. Обычно я делаю централизованные обращения к базе, и если не понятно что приводит к дедлоку, то делается лог всех квориков, открытия таблиц и комитов/ролбеков +/- небольшие опции в зависимости от конретики. Но эту систему большей частью писал не я, соответственно здесь так сделать не получается. Последняя идея была дописать в исходниках айбишных компонент создание такого лога, но мне этот вариант не сильно нравится. Поэтому вопрос - как можно определить какой запрос к базе приводит к дедлоку? Есть идеи?kdv писал(а):дедлок возникает если при попытке модифицировать или удалить (создать версию) записи в одной транзакции сервер обнаруживает на диске версию этой записи, которая принадлежит другой, активной в настоящий момент транзакции.
http://www.ibase.ru/devinfo/mga.htm
Re: deadlock'и при обрывах коннекта
ну ставь обработчик на эксепшены, и огда будет деадлок записывай запрос в файл. в чем проблема ?
Re: deadlock'и при обрывах коннекта
теоретически можно попробовать FBScanner. но явно он дедлоки не ловит, хотя можно посмотреть, что делалось в конкретном коннекте на момент дедлока.
Re: deadlock'и при обрывах коннекта
Я опять со своей проблемой )) Короче я прицепил IBSQLMonitor и записывал 100 последних действий перед эксепшеном. В логах обычная активность, и самое смешное - исключительно селекты. Типа prepare - execute - fetch - fetch ... - fetch. Ещё довольно часто попадал комит, т.е. явно свежая транзакция начинает чтонить читать, и при этом получаю всё тот же lock conflict on no wait transaction. Скажите, может ли быть что IBSQLMonitor пропускает часть обращений к базе? Если нет, то как может появиться update conflicts with concurrent update при селектах?? Понимаю что немного тупой вопрос, но может ли быть update conflicts если не выполняется ни update, ни insert, ни select with lock??
Re: deadlock'и при обрывах коннекта
триггеров на коммит/роллбек нет часом?
Re: deadlock'и при обрывах коннекта
честно говоря даже не знал, что в птице такое есть )) просмотрел все триггеры - только на таблицы, как обычно инсерты/апдейты/делиты. Во всяком случае те, которые IBExpert показывает. Я ведь правильно понял, триггеры на коммит/ролбек они же юзеровские, не системные?dimitr писал(а):триггеров на коммит/роллбек нет часом?
Re: deadlock'и при обрывах коннекта
юзеровские, конечно. В общем, чудес не бывает -- isc_update_conflict выбрасывается только при update/delete и при select with lock, так что ищи глыбже...
Re: deadlock'и при обрывах коннекта
та понимаю что не бывает, в том то и проблема что не могу найти где этот апдейт или делит сидитdimitr писал(а):юзеровские, конечно. В общем, чудес не бывает -- isc_update_conflict выбрасывается только при update/delete и при select with lock, так что ищи глыбже...
такой ещё вопрос, а есть какие-нить системные средства для ведения лога запросов на серваке с фиксацией айдишника транзакции? и если да, то как определить вторую транзакцию, которая приводит к дедлоку? В смысле один айдишник я получаю в ошибке на клиенте, но было неплохо отследить с кем она конфликтует...
Re: deadlock'и при обрывах коннекта
select'ы из таблиц ? А может из процедур ? Которые внутри что-то меняют...vik писал(а):Понимаю что немного тупой вопрос, но может ли быть update conflicts если не выполняется ни update, ни insert, ни select with lock??
Re: deadlock'и при обрывах коннекта
если бы... из таблиц! даже вьюшников нет, только самые обычные таблицы. максимум пара функций вроде addminute используется...hvlad писал(а):select'ы из таблиц ? А может из процедур ? Которые внутри что-то меняют...vik писал(а):Понимаю что немного тупой вопрос, но может ли быть update conflicts если не выполняется ни update, ни insert, ни select with lock??
Re: deadlock'и при обрывах коннекта
ID транзакции, в которой произошла данная ошибка и есть требуемый "второй айдишник". При желании клиент легко может его получить в обработчике данной ошибки перед роллбеком.vik писал(а):как определить вторую транзакцию, которая приводит к дедлоку? В смысле один айдишник я получаю в ошибке на клиенте, но было неплохо отследить с кем она конфликтует...