[JSP] contextDestroyed() wordt niet aangeroepen

[Verwijderd]

Hey,

Ik ben iets aan het maken in JSP en ik heb een contextlistener die correct wordt aangeroepen maar de contextDestroyed() methode wordt niet aangeroepen bij het sluiten van de applicatie. Google gaf me bitter weinig resultaat daarom dat ik hierheen kom.
Volgens mijn boek wordt deze aangeroepen wanneer de applicatie wordt afgesloten, moet ik dan nog wachten op de garbage collector ofzo want de contextDestroyed() methode wordt niet aangeroepen.
Ik ga wachten om code te posten omdat het kan zijn dat ik het principe van contextDestroyed() verkeerd snap.

[momania]

Wat versta jij zelf onder 'de applicatie afsluiten' ?

[Verwijderd]

De browser sluiten

[RedRose]

contextDestroyed wordt aangeroepen als de servletContext wordt afgesloten.

[Verwijderd]

ok, en wanneer gebeurd dit?

[RedRose]

Verwijderd schreef op dinsdag 20 november 2007 @ 19:08:
ok, en wanneer gebeurd dit?

Als de servlet wordt afgesloten

Ok sorry flauw.

Google geeft goeie resultaten op contextDestroyed . Deze method staat ook keurig beschreven in de servlet API specs op java.sun.com.

Zoek ff het verschil op in scope tussen contexts en weet het verschil tussen HTTPServletRequest scope en ServletContext e.d.

[ Voor 55% gewijzigd door RedRose op 20-11-2007 19:17 ]

[Verwijderd]

nu ben ik weer bij het begin, wanneer wordt de servlet gesloten? bij het sluiten van de browser?
en ook, een contextlistener is toch niet gebonden aan een servlet maar aan een applicatie want een container kan meerdere servlets bevatten

[BalusC]

De ServletContext is applicationwide en de contextDestroyed() wordt pas aangeroepen wanneer de hele applicatie (of de server) wordt afgesloten/herstart. Volgens mij zoek je de sessionDestroyed() van de HttpSessionListener. Deze is namelijk sessionwide. Het afsluiten van de browser maakt de sessie inactief. Zodra deze haar timeout heeft bereikt (instelbaar in web.xml), dan zal de sessionDestroyed() worden aangeroepen.

[ Voor 5% gewijzigd door BalusC op 20-11-2007 19:36 ]

[voodooless]

Voor de duidelijkheid, dat is dus niet het moment waarop de user de browser (of tab) webklikt, maar op het moment dat er gedurende x seconden geen pagina meer van betreffende webapp opgevraagd is.

[Verwijderd]

bedankt voor de reply's ik snap nu waarom de app die ik schreef niet werkte. ik zal eens de volledige situatie uitleggen.

De driver en de database URL zitten in mijn DD en worden opgehaald via mijn listener. In deze listener open ik de connectie met de database en steek ik deze in servletContext als attribute zodat ik de connectie telkens kan opvragen.
Ik sluit de verbinding dan in de contextDestroyed, maar deze trad niet op. Ok nu snap ik hoe dit komt. omdat zolang er paginas worden gevraagd aan de servlet blijft deze bestaan, eens de timeout optreed wordt de app werkelijk afgesloten en dus danig ook de database gesloten. (klopt dit?)

Wat is nu feitelijk het probleem, zolang de database niet gesloten wordt komt mijn INSERT statement niet in de database terecht. Wanneer ik mijn database resoluut sluit nadat ik mijn insert doe komt hij er wel in.

Dit is een schoolopdracht want ik ben nog vollop aan het leren hoe Servlets enzo werken.
Ik gebruik een Access Database voor deze oefening

[voodooless]

Iets met autocommit = false en vergeten commit te doen

En kijk eens naar een connectionpool, dat is veel handiger De meeste application servers hebben zoiets wel ingebakken, en anders heeft apache wel een mooie voor je.

[ Voor 67% gewijzigd door voodooless op 20-11-2007 20:23 ]

[Verwijderd]

aangezien het een schoolopdracht is hebben we weinig bewegings ruimte, we werken trouwens lokaal met en tomcat server.

die autocommit = false, wat is dat precies, over welke klasses heb je het?

[voodooless]

google is je vriend

[BalusC]

Inderdaad de connectie committen. En houd de levensduur van een connectie, statement en resultset zo kort mogelijk. Ik hoop maar niet dat je de connectie als een instance variabele van de servlet hebt gedeclareerd

[Verwijderd]

ok, wat heb ik gedaan:

Voor ik mijn connectie in mijn servletContext stop heb ik autocommit(false) gedaan en dan heb ik na het uitvoeren van mijn prepared statement mijn connectie commit() laten uitvoeren. dit is niet gelukt, als ik dit dan doe nadat mijn stmt gesloten is lukt dit ook niet, hier ligt het dus niet aan.
Ik heb een paar testklasses en als ik expleciet de database sluit lukt het wel om een insert te doen, maar dit is dan niet meer volgens de 'oefening'

BalusC schreef op dinsdag 20 november 2007 @ 20:38:
Inderdaad de connectie committen. En houd de levensduur van een connectie, statement en resultset zo kort mogelijk. Ik hoop maar niet dat je de connectie als een instance variabele van de servlet hebt gedeclareerd

niet van mijn servlet, van mijn Context

[ Voor 28% gewijzigd door Verwijderd op 20-11-2007 20:46 ]

[voodooless]

Even iets anders: Hoe test je of de inserts gelukt zijn?

[Verwijderd]

De access database via een klein stukje code uitlezen of gewoon de access db openen

[voodooless]

Tja, als jij de connectie niet sluit is het nogal logisch dat het lijkt alsof er niets gecommit is. Access is nu eenmaal niet gemaakt om er met meerdere instanties tegelijk in te gaan koekeleren.

Probeer dan liever een echte database? Als je toch met java bezig bent is HSQL misschien wel handig.

[Verwijderd]

Ik kan geen andere database gebruiken doordat de oefening specifieert dat het met Access te doen is. Dus zoals het er nu voorstaat:
moet de connectie gesloten en weer geopend zijn voor je kan de nieuwe data opvragen?

[voodooless]

Verwijderd schreef op dinsdag 20 november 2007 @ 20:59:
moet de connectie gesloten en weer geopend zijn voor je kan de nieuwe data opvragen?

Zou niet moeten zijn, zolang je de data maar met de zelfde connectie weer opvraagt moet dat geen enkel probleem zijn.

Dus maak gewoon een servlet dat insert, en een ander dat leest (of beiden in een, whatever je leuk vindt). Als alles goed is moet dit gewoon werken.

[Verwijderd]

Hartelijk dank, het is gelukt, dus zolang de connectie openstaat kan je ermee doen wat je wil, omdat 1 connectie eigenlijk 1 verbinding met de database is. Ik wist dit simpelweg niet, ik dacht dat het de manier van werken was, maar nu ik goed en wel snap wat er gebeurd is dit geen slechte manier van werken, behalve als je de database voor meerdere apps tegelijk wil gebruiken, maar dan nog, als je dan een multi user database hebt, mag het ook geen problemen opleveren


Maar, mijn connectie wordt nog steeds niet gesloten door de contextDestoryed, ik heb in mijn DD de session-timeout op 1 gezet en de applicatie gestopt, de database kwam nog steeds niet vrij na 5 minuten, dan heb ik de server gestopt, dit is ook niet gelukt om de database te sluiten

[ Voor 23% gewijzigd door Verwijderd op 20-11-2007 21:28 ]

[voodooless]

Als je de server netjes stopt zou die contextDestoryed toch echt wel aangeroepen moeten worden. Zet er wat debug info in zodat je dat kunt checken.

[Verwijderd]

Ik had er nog nooit aan gedacht om in deze log te kijken.

code:

20-nov-2007 21:40:29 org.apache.coyote.http11.Http11BaseProtocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8084
20-nov-2007 21:40:30 org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
[Microsoft][ODBC Microsoft Access-stuurprogramma]Ongeldige transactiestatus
20-nov-2007 21:40:31 org.apache.coyote.http11.Http11BaseProtocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8084
20-nov-2007 21:40:31 org.apache.catalina.core.AprLifecycleListener lifecycleEvent
INFO: Failed shutdown of Apache Portable Runtime

dit krijg ik bij het stoppen, hier zie je dus dat access een error geeft

dit krijg ik bij het opstarten van de webapp

code:

SEVERE: Error starting static Resources
java.lang.IllegalArgumentException: Document base C:\Documents and Settings\Jelle\Mijn documenten\Katho\3de Jaar\Lab Java\Oefening 1\WebApplication1\build\web does not exist or is not a readable directory

Dit laatste error is raar omdat hij verwijst naar het eerste dat ik heb gemaakt, ik ben momenteel in een andere map bezig. hoe dit komt dat hij zoekt in een andere map weet ik niet

[ Voor 8% gewijzigd door Verwijderd op 20-11-2007 21:43 ]

[voodooless]

Dat is niet raar, als die map nog bestaat, dan zal daar ook een app gestart zijn, en als je de server stop, stop je ook die app.

[Verwijderd]

voodooless schreef op dinsdag 20 november 2007 @ 22:02:
Dat is niet raar, als die map nog bestaat, dan zal daar ook een app gestart zijn, en als je de server stop, stop je ook die app.

sorry maar nu volg ik niet meer

[voodooless]

Bij het starten van de server worden alle apps gestart, dus ook die, die je eerder aangemaakt hebt.

[Verwijderd]

dus moeten ze allemaal correct afgesloten worden voor de contextDestroyed optreed?

[voodooless]

Nee, dat lijkt me eigenlijk niet.

[Verwijderd]

wat bedoel je dan? ik begrijp niet goed wat je bedoeld

[Creepy]

Je application server zal alle applicaties die hij heeft starten. Dus als je een oudere app hebt gedefineerd in je application server die ook wijst naar die oude directory dan issie dus in gebruik voor je tweede applicatie.

En kom op, in de docs staat prima uitgelegd wanneer de contextDestroyed optreedt, zowel BalusC als voodooless melden het zelfs hier ook nog in het topic. Wat snap je daar nog niet aan?
Lees anders eens wat over de applicationContext en de servletContext, request e.d. en dan snap je hopelijk dat je je verbinding niet op de meest handige plekt declareerd en instantieerd. Als je een databasepool gebruikt (vrij eenvoudig met tomcat) dan wil je dat juist op een zo laat mogelijk doen en je wilt die zo snel mogelijk weer vrijgeven.

Tip: je servlet zelf kan het beste bepalen wanneer er een DB verbinding nodig is. Daar heb je je contextDestroyed niet voor nodig.

[ Voor 11% gewijzigd door Creepy op 21-11-2007 09:30 ]

[Verwijderd]

Er zaten fouten in mijn code ook. Wanneer je dus de server stopt, wordt de contextDestroyed methode aangeroepen.
Bedankt voor alle info, ik ben er veel mee vooruit geraakt.

Sorry voor de soms domme vragen