Zdraweite!

Neka predpolojim che imame prilojenie koeto se wyrzwa mrejovo s baza danni raboteshta wyrhu firebird 1.5.
Kakwo se sluchva ako prilojenieto startira tranzakciq za "Update" na zapis ot tablica v DB i predi da e zawyrshila tranzaciata mrejovata wryzka sys syrvera se razpadne. W tozi sluchai prilojenieto ne moje da kaje Commit ili Rollback na tranzaciata zashtoto niama komunikacia, ot druga strana obache zapisa koito sme opitali da "Update-vame" e zacluchen i ako druga tranzacia se opita da go promeni izliza syobshtenie za "deadlock"(taka i triabva da byde).
Ta waprosa mi e dokoga tozi zapis shte stoi zakluchen, ima li nachin da premahna visiashtata tranzakcia.

Нямам си на идея до кога ще стой заключен записа - по тази причина не мога да ти кажа и как да го оправи6 от приложение, но пробвай с Backup i Restore на базата - създават се връзките отново и в 98% от случаите нещата се оправят.

Ако не се лъжа е 60 секунди таймаут-а на сървъра да дропне клиента и да му ролбакне незавършените транзакции. Пробвай

във firebird.conf гледам че има параметри за настройка, които може да ти свършат работа

DeadlockTimeout
ConnectionTimeout
и а самата TIBTransaction компонента имаше properties от рода IdleTimer - и DefaultAction - Commit/Rollback

иначе при мен се получаваше подобно нещо и решението беше да спра сървиса на Firebird-а и да го пусна отново

Първо благодаря за отговорите.

"иначе при мен се получаваше подобно нещо и решението беше да спра сървиса на Firebird-а и да го пусна отново" - и при мен се получава обаче аз искам да избегна точно този проблем.
"и а самата TIBTransaction компонента имаше properties от рода IdleTimer - и DefaultAction - Commit/Rollback " - аз мислчя че това са храктеристоки на самия компонент TIBTransaction - и ако връзката пропадне след изтичане на IdleTimer ще се опита да изпълни DefaultAction - Commit/Rollback обаче тъй като няма връзка няма да има ефект.
Другото решение е да се направи bakup/restore на БД(както беше писал някой по-горе) - но това също е нежелателно за мен.

Ще провера за ConnectionTimeout.

Значи какво се случва при deadlock :

Транзакция Т1 заключва таблица А. Транзакция Т2 опитва да отвори таблица А. Т1 все още е активна. Транзакция Т2 чака DEADLOCK_TIMEOUT ( задава се в ibconfig ) и ако все още таблица А е заключена thrоw-ва exception "Deadlock". Таблица А ВСЕ ОЩЕ Е ЗАКЛЮЧЕНА.

Така че теоретично ако се разпадне връзката на Т1 със сървъра, таблица А ще си остане заключена завинаги.
Решенията са 3 :
1. Рестарт на service-а. Работи гарантирано винаги.
2. При бекъп/рестор също ще бъдат разкарани всички висящи глупости от базата
3. "Transaction Recovery" от IbConsole. Почти винаги помага


_ _ _

Time is like a drug. Too much of it kills you.

Редактирано от killall на 05.04.04 17:34.

Представата ти за начина на работа на сървъра не е съвсем точна.
Firebird е версионен, а не блокировъчен тип сървър. Тук никога не се заключва таблица. Не се заключва даже и запис. Всяка пишеща транзакция създава версия на записа (т.н. делта) и това не пречи на останалите транзакции да продължат да си работят по начин съответстващ на параметрите си:
[READ WRITE | READ ONLY]
[WAIT | NO WAIT]
[[ISOLATION LEVEL] {SNAPSHOT [TABLE STABILITY] | READ COMMITTED [[NO] RECORD_VERSION]}]
За съществуването на съединението следи менъджера на комуникациите. Ако той открие разпаднато съединение се предава искане за ролбекване на активните транзакции на това съединение към мениджъра на транзакциите. Така, че при разпадане на съединението не става нищо страшно. Имаше един проблем в IB6.0 (ако не ме лъже паметта), но той се получаваше само когато има едновремено връзка по мрежов протокол и локално.
Дори ако сървъра падне аварийно по някаква причина, при следващото отваряне на базата всички транзакции, които са били активни в този момент се ролбекват.
И слава богу (девелоперу), че е така, защото иначе би била немислима работата 24*7.
За повече информация:

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Това за версионността на данните е ясно, но Deadlock -a м/у конкуриращи се транзакции си се случва.
Виж това за connection managera ми беше много полезно.
Проблема всъщност произтичаше от това, че връзката не се разпадаше и аз нямах представа кога ще се рападне.
Всъщност то си пишело обаче трябва някой да чете(н.р. аз):).
В конфигурационния файл на firebird-a е описано как да се справи човек с проблема.
Оказа се че това е проблем на самата ОС - т.е. на какъв интервал сървера изпраща dummy пакет към клиента за да провери дали връзката е жива(имам предвид случая за TCP/IP връзка). По подразбирне този интервал е 2 часа. Ето защо моята транзакция не се е Rollback-нала толкова време.
Както и да е. Важното е че това ми решава проблема.
Благодаря на всички за отговорите.