[es] - Indy9 i IdTCPServer.OnExecute

milika
Milika Delic
RD
NS

Član broj: 13221
Poruke: 120
*.nspoint.net.

Profil

^{25.08.2005. u 19:39 - pre 227 meseci}

Ehe evo mene opet sa thredovima, valjda....

IdTCPServer.OnExecute bi trebalo da odradi konekciju u zasebnom threadu
i tu nastaje frka....

Sta sve treba da uradim sa mojim postojecim funkcijama da bi one radile lepo u OnExecute?

Probao sam ja sa njima i ovako i lepo rade,
ali sa 127.0.0.1 i to je samo jedna konekcija, jelte...

A meni bi trebalo da to radi i sa 500 konekcija kako tako... Napominjem da su funkcije koje rade u threadu male zahtevnosti sto se tice procesorskog vremena i memorija, ali nisu ni malo jednostavne i cak ima i file operacija...

Pomagajte da se resim ove bede...

Pozdrav....

Odgovor na temu

srdjandakic

Član broj: 11297
Poruke: 430
*.sbb.co.yu.

+14 Profil

Re: Indy9 i IdTCPServer.OnExecute

^{26.08.2005. u 13:50 - pre 227 meseci}

OK, pretpostavka, za tvoj program (Milioner) klijent posalje svoj rezultat koji ti upisujes u bazu.

To isto moze da radi N klijenata u isto vreme.

Jedno resenje ti je koristis N konekcija na bazu sto nije resenje :)

Drugo resenje je da u OnExecute blokiras taj deo (poziv jedne jedine TSqlConnection.ExecSQL), recimo, kriticnom sekcijom.

Problem je sto klijent ceka da se svi klijenti izredjaju kako bi on mogao da izvrsi komandu i nastavi rad. Nastavak rada (npr, neka sledeca komanda serveru) se izvrsava u tom istom OnExecute u istom threadu i do nje nece doci sve dok svi klijenti ne odrade njihov ExecSQL.

Ako ti ovo odgovara, onda ti je to najlakse resenje.

Trece resenje (komplikovanije) bi bilo da napravis worker thread u serverskoj aplikaciji, i onda u klijentovom OnExecute saljes komande u queue worker threada za te kriticne operacije.

Znaci klijenti salju komande sa podacima, "pune server poslom" koji se odradjuje u worker threadu, i imaju mogucnost da rade dalje bez cekanja.

Pretpostavka je da ce server uspeti to sve da uradi dok klijent (sporo zivo bice koje radi sa user interfejsom, i komunicira preko interneta) posalje sledecu komandu i ponovi OnExecute.

Ovo nije uvek prakticno, jer imas kasnjenje (tvoje stanje na klijentu ne odgovara uvek stanju na serveru) pa moras da refreshujes ili neki drugi nacin proveris da li je poruka obradjena.

Ali ni ovo nije tesko, npr, posaljes komandu "proveri da li je upisano to i to", u OnExecute se proveri gde se u queue worker threada nalazi onaj SQL od proslog puta. Tu sad imas razne mogucnosti, da uvedes prioritete operacija, prioritete klijenata, itd itd.

Uvek su ti blokirajuce operacije lakse za implementaciju, ali manje fleksibilne u stvarnom radu sa dosta klijenata. Opet, zavisi od tvog problema...

Odgovor na temu

milika
Milika Delic
RD
NS

Član broj: 13221
Poruke: 120
*.nspoint.net.

Profil

Re: Indy9 i IdTCPServer.OnExecute

^{26.08.2005. u 19:34 - pre 227 meseci}

Hvala na opsirnom odgovoru...

Hm, za mene bi idealno bilo drugo resenje, tj sa kriticnom sekcijom.
Operacije u ovoj vrsti komunkacija su, uglavnom, sve istog prioriteta
te onda ne mislim da bi trebalo opterecivati time....

E sad prakticno, kako to najpametnije uraditi, ima li neki promercic u delphi
i indiju, da ne izmisljam toplu vodu?

Hvala puno i pozdrav

Odgovor na temu

srdjandakic

Član broj: 11297
Poruke: 430
*.sbb.co.yu.

+14 Profil

Re: Indy9 i IdTCPServer.OnExecute

^{26.08.2005. u 22:44 - pre 227 meseci}

Hm, pa, nista specijalno... u serverskom modulu definises i kreiras promenljivu section:TCriticalSection.

I onda u OnExecute imas:

Code:

section.Enter;
try
  { zasticeni deo }
  ...
  operacija(a,b,c);
  ...
  { kraj zasticenog dela }
finally
  section.Leave;
end;

_{[Ovu poruku je menjao srdjandakic dana 26.08.2005. u 23:44 GMT+1]}

Odgovor na temu