К базе (через локальные соединения) подключены две программы, которые делают update одной и той же таблице (записи разные, насколько мне представляется).

Пишущие транзакции короткие - они сразу же закрываются после запроса на апдейт.

Первый софт, транзакция: read_committed rec_version.
Второй софт, транзакция: read_committed rec_version nowait.

Есть еще несколько транзакций, они все read_committed
rec_version nowait read, и, думаю, на эту проблему не влияют.

На второй программе происходит deadlock: lock conflict on no wait transaction deadlock.

Через где-то 4 минуты (смотрю всё по эвриковским логам) происходит deadlock на первой программе: deadlock
update conflicts with concurrent update.

Всё это происходит на IB 7.5 и случается достаточно часто (несколько дедлоков в день). На FB 2.1 этой проблемы нет.

Как лучше исправить такую ситуацию?

а почему тогда не юзать ФБ? или "политика Партии такая", строго коммерческое ПО?

Политика - что бы работало везде - и на IB и на FB. У юзеров кое-где стоит IB, и они с него перелезть не могут - часть третьестороннего софта работает исключитетельно под IB.

> У юзеров кое-где стоит IB, и они с него перелезть не могут
> - часть третьестороннего софта работает исключитетельно
> под IB.


В чем проблема? И пусть третьесторонний софт работает на IB.
Что мешает параллельно FB поставить? База чтоль одна и та же?

И как они на одном порту будут работать (некоторые коннекты в софте - сетевые, про них не писал - в глюке не замечены)?

Базы разные.

> И как они на одном порту будут работать


FB можно на другой порт поставить.

Хорошо, строку коннекта нашел, как поменять. Вспомнилось... А GDS32.DLL? Что с ней делать?

Может таки можно что-то с транзакциями придумать? Установка и настройка параллельно FB и IB автоматом - непростая штука. Наши юзеры этим заниматься точно не будут (а ближайшие админы, часто, в 200-300 километрах) - придётся инсталлятором порты править в инишке FB, как-то разруливать проблему с GDS32.DLL. Опять же - юзеры могут переставить FB в любой момент, порт и GDS32.DLL, конечно, никто руками менять не будет... Надёжность системы падает.

> [0] Deadlock fixer   (13.10.09 15:58)

> Через где-то 4 минуты (смотрю всё по эвриковским логам)
> происходит deadlock

Не совсем понятно - софт твой или ты его просто настаиваешь/админишь/сопровождаешь?
Если ты автор - смотри программу: на чем, когда и почему клинит, отлавливай баг и исправляй. Или ты хочешь какую то волшебную галочку поставить, что бы не клинило? Так наверное вряд ли получится.
ИМХО.

> [0] Deadlock fixer   (13.10.09 15:58)
> Всё это происходит на IB 7.5 и случается достаточно часто
> (несколько дедлоков в день). На FB 2.1 этой проблемы нет.

Так вроде никто и не гарантировал идентичность работы этих разных серверов.

> Deadlock fixer   (14.10.09 12:21) [6]

> .. А GDS32.DLL? Что с ней делать?

Класть в каталог программы.

> Deadlock fixer   (14.10.09 12:29) [7]
> Может таки можно что-то с транзакциями придумать?

Апдейт на одной таблице? Завершаются сразу после апдейта? Ну наверное ж заменить no wait на wait...

>Не совсем понятно - софт твой или ты его просто настаиваешь/админишь/сопровождаешь?

Обе программы - мои.

>Если ты автор - смотри программу: на чем, когда и почему клинит, отлавливай баг и исправляй.

В первом сообщении указал - падает на updat'ах базы. Почему - не ясно.

>Или ты хочешь какую то волшебную галочку поставить, что бы не клинило?

Я бы и рад поправить, но не знаю, что. В параметрах обоих транзакций вроде бы прописано всё верно - но от этого не легче.

>Так вроде никто и не гарантировал идентичность работы этих разных серверов.

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

>Апдейт на одной таблице?

Да. (первое сообщение: которые делают update одной и той же таблице).

>Завершаются сразу после апдейта?

Да. (первое сообщение: они сразу же закрываются после запроса на апдейт).

>Класть в каталог программы.

Спасибо, мысль хорошая.

>Ну наверное ж заменить no wait на wait...

Спасибо, попробую.

> [11] Deadlock fixer   (14.10.09 19:00)
> В первом сообщении указал - падает на updat'ах базы. Почему - не ясно.
Ты указал, что
> Через где-то 4 минуты происходит deadlock
Если бы через 40 минут нормально было бы?
Что за апдейты тоже непонятно. TTable.Edit в цикле тоже через Update работает.

> (записи разные, насколько мне представляется)
А нам что должно представляться?

> хочется сделать так, что бы работало и там и там
А как сделано то?

>Если бы через 40 минут нормально было бы?

Нет.

>Что за апдейты тоже непонятно

update some table where some condition. Ничего выдающегося.

>TTable.Edit в цикле тоже через Update работает.

Ничего визуального нет.

>А нам что должно представляться?

Я уточню этот момент.

>А как сделано то?

К базе (через локальные соединения) подключены две программы, которые делают update одной и той же таблице (записи разные, насколько мне представляется).

Пишущие транзакции короткие - они сразу же закрываются после запроса на апдейт.

Первый софт, транзакция: read_committed rec_version.
Второй софт, транзакция: read_committed rec_version nowait.

Есть еще несколько транзакций, они все read_committed
rec_version nowait read, и, думаю, на эту проблему не влияют.

> [14] Deadlock fixer   (15.10.09 18:00)

Ты можешь хоть стихами ОПИСАТЬ свои программы, хоть красками. Даже клип снять про четвертую минуту.
А можешь просто привести куски кода на которых происходит блокировка.

И чем обусловелно применение разных режимов блокировки в разных софтах?