iBase.ru Forum

значит покопался я со всем этим, и картина счас следующая: на всех машинах периодически вылетает "lock conflict on no wait transaction deadlock update conflicts with concurrent update concurrent transaction number is [integer]", в логе птицы ерроры 10054 и 10061. Однозначно определить связь ни со сбоями сетки, ни с действиями операторов не удалось. Теоретически дедлоков быть не должно, но ясен пень что теория с практикой разошлась. Вопрос номер раз - как определить связаны ли эти дедлоки с логикой проги или же с работой сети?
з.ы. транзакция nowait read_committed rec_version

kdv писал(а):А деврейсов лупить надо за исправление дефолта.

Ну, отлупить кого-то - это всегда приятно. Но деврейсы просто играют ту музыку, за которую платят деньги. По воплям трудящих. Но отлупить - это я всегда за...

vik писал(а):Вопрос номер раз - как определить связаны ли эти дедлоки с логикой проги или же с работой сети?

Мировая статистика говорит о том, что на 1000 конфликтов из-за логики приходится 1 из-за сети...

Сча наверно бить будут, но все таки рискну спросить ) я перекопал кучу вариантов, но так и не смог определить где именно этот дедлок вылетает. Можете подкинуть идеи как найти кусок, который приводит к возникновению дедлоков?

дедлок возникает если при попытке модифицировать или удалить (создать версию) записи в одной транзакции сервер обнаруживает на диске версию этой записи, которая принадлежит другой, активной в настоящий момент транзакции.
http://www.ibase.ru/devinfo/mga.htm

kdv писал(а):дедлок возникает если при попытке модифицировать или удалить (создать версию) записи в одной транзакции сервер обнаруживает на диске версию этой записи, которая принадлежит другой, активной в настоящий момент транзакции.
http://www.ibase.ru/devinfo/mga.htm

Я знаю как они возникают и как их устранить. Проблема в том, что я не могу найти операцию в клиенте, при которой этот дедлок вылетает. Обычно я делаю централизованные обращения к базе, и если не понятно что приводит к дедлоку, то делается лог всех квориков, открытия таблиц и комитов/ролбеков +/- небольшие опции в зависимости от конретики. Но эту систему большей частью писал не я, соответственно здесь так сделать не получается. Последняя идея была дописать в исходниках айбишных компонент создание такого лога, но мне этот вариант не сильно нравится. Поэтому вопрос - как можно определить какой запрос к базе приводит к дедлоку? Есть идеи?

ну ставь обработчик на эксепшены, и огда будет деадлок записывай запрос в файл. в чем проблема ?

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

Я опять со своей проблемой )) Короче я прицепил 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??

триггеров на коммит/роллбек нет часом?

dimitr писал(а):триггеров на коммит/роллбек нет часом?

честно говоря даже не знал, что в птице такое есть )) просмотрел все триггеры - только на таблицы, как обычно инсерты/апдейты/делиты. Во всяком случае те, которые IBExpert показывает. Я ведь правильно понял, триггеры на коммит/ролбек они же юзеровские, не системные?

юзеровские, конечно. В общем, чудес не бывает -- isc_update_conflict выбрасывается только при update/delete и при select with lock, так что ищи глыбже...

dimitr писал(а):юзеровские, конечно. В общем, чудес не бывает -- isc_update_conflict выбрасывается только при update/delete и при select with lock, так что ищи глыбже...

та понимаю что не бывает, в том то и проблема что не могу найти где этот апдейт или делит сидит

такой ещё вопрос, а есть какие-нить системные средства для ведения лога запросов на серваке с фиксацией айдишника транзакции? и если да, то как определить вторую транзакцию, которая приводит к дедлоку? В смысле один айдишник я получаю в ошибке на клиенте, но было неплохо отследить с кем она конфликтует...

vik писал(а):Понимаю что немного тупой вопрос, но может ли быть update conflicts если не выполняется ни update, ни insert, ни select with lock??

select'ы из таблиц ? А может из процедур ? Которые внутри что-то меняют...

hvlad писал(а):

vik писал(а):Понимаю что немного тупой вопрос, но может ли быть update conflicts если не выполняется ни update, ни insert, ни select with lock??

select'ы из таблиц ? А может из процедур ? Которые внутри что-то меняют...

если бы... из таблиц! даже вьюшников нет, только самые обычные таблицы. максимум пара функций вроде addminute используется...

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

ID транзакции, в которой произошла данная ошибка и есть требуемый "второй айдишник". При желании клиент легко может его получить в обработчике данной ошибки перед роллбеком.