thread kezelés sql esetén

 ( kaltsi | 2012. július 1., vasárnap - 1:21 )

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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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.

Mint üzemeltető agyfaszt kapnék ha a fejlesztő azzal állna elő, hogy az sql szerverre (is) telepítsem fel a tákolmányát.

De ez csak az én véleményem.

vl kollega arra gondolhatott, hogy valami tárolt eljárásban
kellene összehozni a túl érzékeny részeket, tehát a kliensnek
csak a lekérdezés marad.

Ezzel meg nem kerultuk meg a lehetseges halozati hibat.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Hát, nem is erre gondoltam... :D

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

A baj ott kezdődik, ha a kapcsolat csak szinkron módban tud
dolgozni, mert akkor nincs lehetőséged egyéb módon
"tesztelni", pl. select 1 from dual.
Be tudod állítani az aszinkron módot?

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.

Egyszerűen akartam fogalmazni .... :)

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.

  1. Miért lesz lag? Wifi? Mobilnet?
  2. Meddig tart? 60ms? 5-10 perc?
  3. Miért nem fogja észrevenni a kliens? Rosszul megírt program?
  4. 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).
  5. Egyéb