[es] - Deadlock u Interbase-u/FirBird-u

doroz
Zoro Zoro

Član broj: 37127
Poruke: 39
*.adsl.net.t-com.hr.

Profil

^{03.08.2006. u 07:41 - pre 215 meseci}

Problem je ovakav...

Imam aplikaciju koja radi na mrezi...
Radi na interbase-u odnosno na firebird-u...

Korisnik1: Editira red u tablici i posta (bez commitanja)
Korisnik2: Editira isti red u tablici - javlja se deadlock

Ta tablica ima trigger (before update) koji mijenja podatke tom redu... tako da ga se cesto editira i posta

Da li se moze postavi automatsko commitanje te tablice poslje posta a da mi ne zatvara tablice ili jos bolje staviti commitanje u trigger koji ta tablica ima ili napraviti trigger after post koji ce commitati

Odgovor na temu

schild
Dejan Šild
TopCode Software
Subotica

Član broj: 59888
Poruke: 138
*.legendww.com.

Sajt: www.topcode.rs

+2 Profil

Re: Deadlock u Interbase-u/FirBird-u

^{03.08.2006. u 10:45 - pre 215 meseci}

Citat:

doroz: Problem je ovakav...
Ta tablica ima trigger (before update) koji mijenja podatke tom redu... tako da ga se cesto editira i posta

Da li se moze postavi automatsko commitanje te tablice poslje posta a da mi ne zatvara tablice ili jos bolje staviti commitanje u trigger koji ta tablica ima ili napraviti trigger after post koji ce commitati

Ne možeš commit-ovati transakciju u triggeru, niti u proceduri. Ali možeš u DataSet.AfterPost da dodaš ... MyTrans.CommitRetaining (MyTrans je komponenta koju koristiš za kontrolu transakcije tog dataseta).
CommitRetaining ti radi samo u FB (nisam 100% siguran ali mislim da je tako), i to znači da je uradio Commit, ali ti ne zatvara transakciju, tako da možeš nastaviti rad u njoj. Ali je vrlo preporučljivo da pre zatvaranja forme ipak uradiš pravi Commit, zbog nekih internih stvari u FB.

A to što nešto menjaš u triggeru Before Update ne bi trebalo da smeta, osim ako si nešto zakomplikovao. Promene bi trebalo da radiš u sledećem stilu:
new.MyField = 100;
a ne
Update MyTable set MyField = 100 .... where new.pk=....

Odgovor na temu

doroz
Zoro Zoro

Član broj: 37127
Poruke: 39
*.adsl.net.t-com.hr.

Profil

Re: Deadlock u Interbase-u/FirBird-u

^{03.08.2006. u 14:51 - pre 215 meseci}

trigger nije kopliciran...

vuce neke sume iz drugih tablica...
ali commmitretaining nije dobro rijesenje (zbog petlji)

naso sam komponente fibplus koje imaju autocommit koji odgovara i radi sta ja hocu

Odgovor na temu

morlic
Milos Orlic
Beograd

Član broj: 6081
Poruke: 735
*.dynamic.sbb.co.yu.

+1 Profil

Re: Deadlock u Interbase-u/FirBird-u

^{03.08.2006. u 15:30 - pre 215 meseci}

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.

Odgovor na temu