Deadlock u Interbase-u/FirBird-u

CommitRetaining ne treba koristiti, u nekim slucajevima koriscenja moze doci i do ozbiljnih problema. Inace je postojao jos u IB-u. Programera lako ponese jedina njegova svetla strana da kursori nad bazom ostaju otvoreni posle njegovog izvrsenja sto nije slucaj sa cistom commit varijantom. Ali i to se da srediti sa pametnim pristupom.

U svakom slucaju stvari funkcionisu ovako:

Onog trenutka kada korisnik A izmeni neki slog a ne zatvori transakciju taj slog ostaje zakljucan (server postavlja lock na njega) za druge korisnike i njihove transakcije dokle god korisnik A ne uradi commit ili rollback. Zato transakcije treba da budu sto krace kao bi eventualna zakljucavanja bila sto kraca. Otvaranje transakcije prilikom ulaska u neku formu i njeno zatvaranje po izlasku iz forme je veoma lose resenje kada se na bazu kaci vise od jednog korisnika istovremeno, a moguce je napraviti problem i sa jednim korisnikom koji startuje dve transakcije koje rade nad istim podacima. To znaci da korisnik Pera moze da otvori tu formu i da ode na dorucak, pri tome blokirajuci rad drugih korisnika dokle god se ne vrati sa dorucka. Znaci transakcije sto krace treba da traju, i ako je to moguce da se ne preteruje sa kolicinom izmena u okviru jedne transakcije. Ovo je zbog toga sto svaka transakcija trosi odredjene resurse na serveru i sto moze doci do negativnog uticaja na performanse i stabilnost servera.

FIB moze da radi u rezimu kratkih transakcija, i nema ovaj problem; otvara transakciju da bi uzeo podataka i odmah je zatvara, isto tako i prilikom insert, update i delete komandi. Medjutim ukoliko je potrebno vezati vise izmena nad bazom mora se rucno startovati i zatvoriti transakcija pod kojom se rade te izmene, naravno gledajuci da to traje sto krace.