Nedoumica oko transakcija

Interesuje me sta mislite o transakcijama i kako raditi sa njima.

Rad sa izdvojenog mesta preko neta je u pitanju.Sa dugackim unosima(prosecno preko 100 rekorda).Vise korisnika.

Dali je bolje za svaki rekord otvoriti pa zatvoriti transakciju,ili pak otvoriti transakciju pa sacekati da se zavrse svi unosi od jednog klijenta pa zatvoriti transakciju.

Poenta price je ako dobijem polovicne podatke (za svaki unos da zatvaram transakciju a ne odradi se sve sta je trebalo da se posalje) -to su ne upotrebljivi podaci koji zahtevaju kasniju doradu od strane korisnika.Ali transakcija traje kratko sto je kao dobra varijanta.

Dok u drugom slucaju otvorena transakcija traje dugo sto kazu da je losa varijanta (mada meni vise odgovara jer ako ne stignu svi nece ni jedan podatak),mada sa druge strane sa koliko transakcija firebird moze da barata u jednom trenutku i dali mu je problem da radi sa vise otvorenih transakcija?

> Dali je bolje za svaki rekord otvoriti pa zatvoriti transakciju,ili pak otvoriti transakciju pa sacekati da se zavrse svi unosi od jednog
> klijenta pa zatvoriti transakciju.

Transakcija treba da obuhvati jednu logičku operaciju, da li je to unos jednog ili hiljadu slogova zavisi od poslovne logike.

> Dok u drugom slucaju otvorena transakcija traje dugo sto kazu da je losa varijanta (mada meni vise odgovara jer ako ne stignu svi nece ni jedan
> podatak),mada sa druge strane sa koliko transakcija firebird moze da barata u jednom trenutku i dali mu je problem da radi sa vise otvorenih transakcija?

Treba se truditi da transakcije budu kratke, snapshot transakcije koje dugo traju inhibiraju garbage collection što u dužem vremenskom periodu može doneti usporenje. Mislim da ti je bolje da unete podatke keširaš u lokalu (u memoriji ili u lokalnoj bazi) i kada se sve završi da ih pošalješ na server. Time ujedno rešavaš i nastavak rada u slučaju nasilnog prekida, npr. nestanka struje.

Potpis

Do not be a help vampire (http://slash7.com/pages/vampires), use the google.

How to ask questions the smart way:
http://www.catb.org/~esr/faqs/smart-questions.html
http://solair.eunet.rs/~fangor...stions/smart-questions.sr.html

Nakon duzeg perioda eksperimentisanja i kojekakvih probi mislim da ova tema zasluzuje malo vecu paznju pa pomislih da je ponovo aktiviram..

Naime predpostavimo da neka transakcija ipak mora dugo da traje,primera radi,
triger odradjuje posao ali da bi aplikacija videla razultat zahteva ApplyUpdates(0) bez Commit(TD),(navodim kao primer code iz BCB),i recimo da se radi oko 1000 rekorda koji moraju kao celina da se unesu(sto po pravilu bez obzira na operatorovu umesnost mora dugo da traje),tacno je da inhibira garbage collector,ali isto tako mislim da ne usporava sever(to sam probao eksperimentom)...isto tako mislim da pravilno formirana transakcija moze i mora da izdrzi dugacak period postojanja transakcije bez obzira na uslove...

Uporedjivao sam neke popularne programe i koliko vidim malo ko tj. niko o tome ne vodi racuna(iz postovanja prema mukotrpnom radu programera ne navodim programe koje sam uporedjivao) ...primera radi ostave zaglavlje ali ako transakcija se ne zavrsi nema stavki ali zaglavlje ostane da visi(prica vazi za oko najcesceg nacina rada zaglavlje, stavke ,veza id ,pojasnjenje za manje upucene,verovatno nepotrebno)...

Moj stav je ako se otvori transakcija bez obzira na duzinu transakcije, server mora da je omoguci i spravno, ali ne na ustrb performansi izvrsi ili ponisti(u slucaju prekoracenja odredjenog vremenskog perioda) pokrenutu transakciju...

Zanima me Vas stav oko dugih transakcija,za kratke transakcije mislim da nije problem i one se izvrsavaju bez problema ali oko dugih transakcija je sasvim druga prica....

> Naime predpostavimo da neka transakcija ipak mora dugo da traje,primera radi,
> triger odradjuje posao ali da bi aplikacija videla razultat zahteva ApplyUpdates(0) bez Commit(TD),(navodim kao primer code iz BCB),i recimo da se
> radi oko 1000 rekorda koji moraju kao celina da se unesu(sto po pravilu bez obzira na operatorovu umesnost mora dugo da traje),tacno je da
> inhibira garbage collector,ali isto tako mislim da ne usporava sever(to sam probao eksperimentom)...

Zavisi od optrećenja, primera radi ako imaš stotinak novih transakcija u minuti i nekoliko koje traje više sati, primetiće se. Dugotrajna transakcija ne utiče samo na garbage collection već i na startovanje novih.

> isto tako mislim da pravilno formirana transakcija moze i mora da izdrzi dugacak period postojanja transakcije bez obzira na uslove...
> Moj stav je ako se otvori transakcija bez obzira na duzinu transakcije, server mora da je omoguci i spravno, ali ne na ustrb performansi
> izvrsi ili ponisti(u slucaju prekoracenja odredjenog vremenskog perioda) pokrenutu transakciju...

To će svaka baza podržati, to nije sporno, transakcija može trajati i danima ali to nije optimalno rešenje.

> programe koje sam uporedjivao) ...primera radi ostave zaglavlje ali ako transakcija se ne zavrsi nema stavki ali zaglavlje ostane da visi(prica
> vazi za oko najcesceg nacina rada zaglavlje, stavke ,veza id ,pojasnjenje za manje upucene,verovatno nepotrebno)...

Pretpostavljam da misliš na varijantu dokument/stavke, osim ako nema bitnih razloga greška je čim se otpočne unos otvoriti transakciju napraviti parent dokument i redom dodavati child stavke. Bolje je te promene čuvati u lokalu i tek na kraju kada se sve potvrdi uneti izmene u bazu, eliminišući negativne efekte na bazu.

> Zanima me Vas stav oko dugih transakcija,za kratke transakcije mislim da nije problem i one se izvrsavaju bez problema ali oko
> dugih transakcija je sasvim druga prica....

Sve baze koje koriste multi-generational sistem (IB, FB, Postgree, mislim i MS SQL u nekim varijantama) će osetiti uticaj dugotrajnjih transakcija. Naravno taj uticaj je zanemarljiv i nemerljiv ako se radi o slabo opterećenoj bazi, par korisnika sa pretežnim SELECT kverijima.

Potpis

Do not be a help vampire (http://slash7.com/pages/vampires), use the google.

How to ask questions the smart way:
http://www.catb.org/~esr/faqs/smart-questions.html
http://solair.eunet.rs/~fangor...stions/smart-questions.sr.html