Добрый день.
Тема не новая но что-то не выходит решить проблему.
Есть у нас очень капризный клиент, точнее не клиент, а их сеть, у них время от времени лагают куски сети и в результате получаем зависшие транзакции. Как решение придумали показывать номер транзакции с которой происходит самоблокировка и далее уже используя ibexpert удаляем её вручную, но это ж блин издевательство...

Прошу помощи у тех кто хорошо разбирается в данном вопросе, поможет ли мне мониторинг таблицы RDB$TRANSACTIONS, согласно http://firebirdsql.su/doku.php?id=rdb_transactions этой статье здесь указывается является ли транзакция зависшей или нет, но что-то через тот же IBExpert я не смог увидеть там каких-либо изменений.

Транзакции в IBexpert, да и в программе настроены вот так


Вариант с KeepAlive уже пробовали но как-то он не помог. Да и я читал что он не всегда помогает. Да и не настраивать же каждый раз у клиентов, особенно скажем если такое происходит раз в полгода.

Может кто-нибудь подсказать или может носом ткнёт в толковую статью, а то я запросто мог чего и не доглядеть? 

тогда тебе на sql.ru или ibase.ru   

Так не честно   

это пишущие или читающие?

И те и другие. Я по сути не делю транзакции на пишущие и читающие, хотя есть отдельные только для чтения, но таких единицы.

Кстати по ходу уточнение/дополнение.

Насколько мне будут страшны  зависшие транзакции, если я использую метод оптимистичного блокирования? Т.е. по сути ранее я использовал пессимистичное блокирование. Теперь же у меня появился свой механизм блокировок(спец табличка) который позволяет точно определить пользователя который сейчас работает с конкретной записью. И блокировочный механизм компонентов доступа я переключил в оптимистичный вариант.

Мне кажется твоя проблема изначально в неправильном дизайне приложения.
Пишущая транзакция должна быть максимально короткой по времени.
А так получается:
- пользователь вызвал форму редактирования и ушел чай пить, при этом открыта пишущая транзакция и запись заблокирована
- обрыв связи...


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

Добавлено через 1 минуту и 38 секунд
ты пока что не рассказал, что там у тебя да как
по идее зависших транзакций вообще не должно быть
или ты выполняешь Update with lock?

Добавлено через 2 минуты и 36 секунд
а это читал?
http://ibase.ru/devinfo/keepalive.htm

Да, такой трюк пробовал, но что-то не пошло.


Нет у меня Select with Lock, если я правильно понимаю.
Ну во всяком случае так было раньше. Сейчас блокировки нет или во всяком случае быть не должно(где-то могло остаться пессимистичное блокирование).

Сейчас делается попытка перевести если не весь проект, то хотя бы большую часть по следующему принципу:
1) Пользователь прочитал данные.
2) Завершаем транзакцию.
3) Пользователь нажимает Сохранить и тогда запускается пишущая транзакция, и делается изменение данных.



Хм... я чувствовал что где-то что-то не так сделано, ладно попробую реализовать так. Пока не шибко понимаю как именно это будет работать.

Чтающие транзакции (ReadOnly) могут быть открыты сколь угодно долго. Зачем их завершать?

Добавлено @ 11:26

А что сложного в том, что пишущую транзакцию нужно открывать непосредственно перед сохранением?
В FibPlus это вообще всё почти на полноv автомате. Даже транзакциями управлять не нужно.

Логика примерно такая:
- FibDataSet.Edit;
- указать значения полей;
- FibDataSet.POST;

всё 

Ну там фактически получается что-то вроде отключения от БД. Пока пользователь там что-то чухает можно спокойно его отключить и меньше трафика по сети гуляет 

Так как проектов несколько, есть и на других СУБД было решено отказаться от FIBPlus, сейчас работаю с AnyDAC, получается универсальная платформа которую надо затачивать под конкретную СУБД чуть-чуть буквально.

А проблема транзакций тянется ещё со времён динозавров, которую между делом думаю решить.


Кстати AnyDAC работают куда шустрее, чем FIB... Хотя у первых есть отдельные недоработки, но у них и поддержка куда шустрее.

http://www.ibase.ru/devinfo/norecver.htm