[Oracle 10g] trigger before logoff ook bij killed session

[Maniakje]

Ik ben op zoek naar een manier om een PL/SQL blok uit te voeren wanneer een database session beëindigd wordt.

Dit kan met een

code:

TRIGGER BEFORE LOGOFF ON DATABASE

Dat werkt prima wanneer de client een normale logoff doet. De trigger wordt echter niet afgevuurd wanneer de sessie hardhandig wordt verbroken, zoals door een crashende client of wanneer de sessie gekilld wordt. Is het mogelijk om ook dat te ondervangen?

Precies dezelfde vraag is al eens gesteld op het forum van experts-exchange:
http://www.experts-exchan...acle/10.x/Q_22548824.html
(De inhoud van de antwoorden is te bekijken door helemaal naar de bodem van de pagina te scrollen).

Het antwoord wat daar gegeven wordt is dat je periodiek de v$session tabel kunt pollen. Dat is echter niet helemaal wat ik zoek omdat je op die manier altijd achter de feiten aanloopt.

Bestaat er nog een andere manier om dit aan te pakken?

[mphilipp]

Volgens mij gaat er niets 'af' als je een sessie killed of als ie crashed. Oracle komt er zelf ook niet zo snel achter dat een sessie weg is. Als je dead client detect niet goed hebt staan, blijft de sessie zelfs gewoon doorlopen.

Ik denk dat dit best lastig is. Misschien helpt het als we het doel van de actie weten? Wie weet is er een alternatief te bedenken.

[Maniakje]

Ik zal eerst even toelichten waarvoor het gebruikt wordt.

Er bestaat een tabel APPUSER, waarin de gebruikers van de client-applicatie staan. Wanneer de applicatie gestart wordt en een gebruiker inlogt, wordt de oracle-sessie van de applicatie gekoppeld aan een gebruiker uit APPUSER. De koppeling staat in de tabel APPUSER_SESSION, en wordt gebruikt binnen verschillende package functies, die dan aan de oracle-sessie kunnen zien welke gebruiker de aanroep doet.

Als de verbinding verbroken wordt, moet het record van die sessie uit APPUSER_SESSION verdwijnen. Ik wil dat record graag zonder vertraging laten verdwijnen, omdat de koppeling ook in de omgekeerde richting wordt gebruikt; bij een gebruiker wordt ook gezocht welke oracle-sessions erbij horen.

Bovenstaand voorbeeld is een beetje vereenvoudigd, in werkelijkheid wordt er meer dan alleen een gebruiker aan de oracle-sessie gekoppeld, zoals de verschillende devices waarop een gebruiker is ingelogd en een aantal zaken uit de business logica. Het idee blijft echter hetzelfde.


Ik ben momenteel heel naïef aan het onderzoeken of het mogelijk is een trigger after update op v$session te zetten, hoewel ik zelf al niet verwacht daar ver mee te komen.

[ Voor 4% gewijzigd door Maniakje op 19-02-2009 13:43 ]

[leuk_he]

Maniakje schreef op donderdag 19 februari 2009 @ 13:39:
Ik ben momenteel heel naïef aan het onderzoeken of het mogelijk is een trigger after update op v$session te zetten, hoewel ik zelf al niet verwacht daar ver mee te komen.

V$session is een view.

Maar als je nu queried op een view die een join doet van jouw sessie tabel met v$session, dan levert die geen rijen op als de sessions weg is?

[mphilipp]

Maniakje schreef op donderdag 19 februari 2009 @ 13:39:
Ik zal eerst even toelichten waarvoor het gebruikt wordt.

Als de verbinding verbroken wordt, moet het record van die sessie uit APPUSER_SESSION verdwijnen. Ik wil dat record graag zonder vertraging laten verdwijnen, omdat de koppeling ook in de omgekeerde richting wordt gebruikt; bij een gebruiker wordt ook gezocht welke oracle-sessions erbij horen.

Misschien is het een optie om het om te draaien: check of er nog oude sessies geregistreerd zijn (en die geen V$SESSION record meer hebben natuurlijk) en ruim dan de boel op. Gecombineerd met een stukje code die elke 5 minuten (oid) checkt of APPUSER_SESSION nog overeenstemt met V$SESSION.
Is niet helemaal wat je wilt, maar ik denk het maximaal haalbare.
En op OS nivo? Als je bijvoorbeeld onder *nix zit, kan ik me voorstellen dat je een scrippie kan bakken die getriggerd wordt door een aflopende sessie. Die kan dan vervolgens een cleanup proces in de db aftrappen.

Ik raaskal ook maar wat...kan zo even niet bedenken hoe die 'netjes' binnen Oracle geregeld kan worden. Misschien heb je er wat aan.