thread kezelés sql esetén

Fórumok

Lenne egy érdekes kérdésem felétek. Egy oracle sql kezelést thread segítségével oldanék meg, hogy a teljes dolgot ez a thread kezelje le, és fogadja a kéréseket, illetve továbbítsa az eredményt a főprogram felé. Ha bármi gond lenne az sql kapcsolattal, vagy nem érkezne időn belül válasz a thread-től, akkor megszüntetném, majd legenerálnám újra.

Egyesek szerint ez az igazi erőforrás zabáló megoldás, mivel a thread megszűnésekor nem szabadulnak fel az sql kezelési erőforrások, mint a cursor, a descriptor-ok, stb ... .

Ezzel kapcsolatban van valakinek tapasztalata, vagy véleménye?

Hozzászólások

Ha megoldható, akkor inkább job-ot használnék. A lehető legkevesebb
időt, hálózati forgalmat és erőforrást adnám oda a kliensnek.
De nagyvonalakban leírhatnád mire kellene a thread!

Az a probléma állhat fel, hogy egy nem keepalive kapcsolatot támogató sql rendszer esetében (most ne térjünk ki, hogy miért) előfordul olyan hálózati szitu, mikor a tcp kapcsolat a server oldalon már lebomlott, de a kliens erről nem értesül.
Viszont a kliens ekkor végtelen ideig vár a kérésére. Ha ezt egy thread kezelné, akkor tudna egyszerűbben lehetne időzítőt készíteni a válasz várására. Ha időtúllépés lép fel, akkor kikényszerítve megtenné azokat a lépéseket, melyek a szóban forgó sql kapcsolat lebontásához kellenek, vagy megkérni a thread-et, hogy legyen kedves hagyja abba a futást. Ezzel kiküszöbölve azt, hogy az egész folyamat leálljon semmilyen kontroll nélkül.
Lehet nem ez a legjobb megoldás, de a feltételek sajnos adottak, és ehhez kell a legjobb megoldást kitalálni.

Erre az a megoldás, hogy kliensprogramot (egy részét) a szerverre magára kell rakni, ahonnan garantáltan hálózati hibák nélkül látja a szervert. Aztán ezt a részét a kliensednek már úgy éred el, ahogy neked jólesik, nyilván olyan timeoutokat raksz bele, amilyet akarsz a saját protokollodba.

Igen, amennyiben az üzemeltető és a fejlesztő közül a üzemeltetőnek van több esze, tudása, és tapasztalata, akkor jogos a félelem (php-Pistikéken edződött rendszergazdák). Mondjuk ekkor van kb. realitása annak, hogy "Az" sql szerverről beszélünk általánosságban, nem pedig az alkalmazás dedikált sql szerveréről. Mert rendes alkalmazásokhoz azért rendszerint dukál saját Oracle szerver.

Ebben igazad van, de a dedikalt Oracle szerver is nalam egy appliance, vagyis csak az van rajta, mas semmi. Ez azt jelenti, hogy hacsak nem APEX-ban vagy Oracle Forms-ban van irva az app, eselytelen bekeruljon az Oracle melle.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Arra gondoltam, ha két session lenne, akkor a thread-be
be lehetne tenni valami ellenőrzést, tehát a főprog-nak
van egy session-ja azt kiolvassuk : SELECT SYS_CONTEXT('USERENV','SESSIONID') FROM Dual

és a kapott értékkel egy másik session-ban(ez lenne a threadben)
figyelnénk így : SELECT s.saddr, s.sid, s.serial#, s.username,
s.osuser, s.machine, s.program, s.logon_time, s.status,
p.program, p.spid
FROM v$session s, v$process p
WHERE s.paddr = p.addr
AND s.AUDSID IN (a fenti select értéke)
AND egyéb szűrés, pl. gépnév, usernev, stb

ha ez nem ad eredményt, netán inactive akkor leállt a főprog.
Persze itt két connection van, ez nem mindig járható út...

Az a véleményem, hogy a threadek működéséről nagyon halovány fogalmaid vannak, ha "megszüntetésről" meg "legenerálásról" gondolkodsz.
Threadet sosem szüntetünk meg. Megkérjük illedelmesen, hogy amikor neki legközelebb jólesik, legyen szíves exitálni. Természetesen előtte a thread minden általa allokált objektumot szépen felszabadít.

Ja, csak nem mindegy, hogy megszüntetés alatt terminate-et értesz vagy valami signal, flag, akármi alapú megoldást ahol a thread maga figyel az ilyen irányú kérdésre és szépen felszabadít mindent amit kell.
(Ez utóbbira vonatkozott a "Megkérjük illedelmesen, hogy amikor neki legközelebb jólesik, legyen szíves exitálni.")

Mert ha nem lenne eddig világos, ha terminate-tel kilősz egy threadet akkor az csak simán leáll, és bár a thread-hez közvetlenül tartozó erőforrások (amiket a thread indításakor a rendszer létrehozott) felszabadulnak, de minden más amit a te kódod foglalt le marad a helyén.
(Erről szól a "Egyesek szerint ez az igazi erőforrás zabáló megoldás, mivel a thread megszűnésekor nem szabadulnak fel az sql kezelési erőforrások, mint a cursor, a descriptor-ok, stb ... ." mondat)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

de minden más amit a te kódod foglalt le marad a helyén.

Nem! Nem csak az, amit a "te kódod" foglalt! Az is, amit a te kódodból hívott, zárt forrású, masszívan aluldokumentált idegen library (pl. Oracle kliens) foglalt, az is! És erre _semmilyen_ ráhatásod nincs, még debuggolni se nagyon tudod.

Ezért ez a lehetőség gyakorlatilag nem létezik, már ha működő kódot akar valaki írni.

"Nem! Nem csak az, amit a "te kódod" foglalt! Az is, amit a te kódodból hívott, zárt forrású, masszívan aluldokumentált idegen library (pl. Oracle kliens) foglalt, az is! És erre _semmilyen_ ráhatásod nincs, még debuggolni se nagyon tudod."

Hogy egy zárt vagy nyílt, alul- vagy felüldokumentált library mit csinál az ebből a szempontból tökéletesen indifferens. Ha az adott lib rendelkezik valamilyen release, free, close, akármi fv-nyel/mechanizmussal amit normális esetben meg kéne hívnom, de a thread terminate miatt nem tettem meg, akkor az történt, hogy az én kódom foglalt le egy erőforrást amit nem szabadított fel.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Elvben nem rossz ötlet, gyakorlatilag viszont keresnék egy olyan library-t, ami ezt megvalósítja, mert jó sok helyen el lehet rontani.
--
Gábriel Ákos

Jóval bővebb kifejtésre lesz szükségünk a problémáról.

  • Miért lesz lag? Wifi? Mobilnet?
  • Meddig tart? 60ms? 5-10 perc?
  • Miért nem fogja észrevenni a kliens? Rosszul megírt program?
  • Mi történik az oracle és a kliens között, hogy sokáig tart? Sok adat megy át? Akkor egy appszervert be kéne raknod amire csak átköpöd az adatot, oszt az elplsqlezik (lol) magában, és már oracle-vel se kell klienseken kínlódnod (csak egy helyen, az appszerveren).
  • Egyéb