DB Verbindung in WebApplication nach einem Tag weg

[flo_hr]

Hallo,
ich habe eine WebApplication die in einem Tomcat 6.0.16 läuft. Diese WebApp greift auf eine MySQL Datenbank zu.

Es funktioniert alles einwandfrei, wenn ich aber am nächsten Tag mich einloggen will, wird eine Exception geworfen. Die Exception tritt bei der Methode auf, bei der ich die Datenbank-Abfrage mache.

Hat jemand eine Idee, warum es nicht funktioniert

Gruss Flo

 

[Oliver Gierke]

Wie sieht denn die Exception aus? Was sagt das Tomcat / MySQL Log aus?

Gruß
Ollie

 

[flo_hr]

06.04.2008 13:36:54 org.apache.catalina.core.StandardWrapperValve invoke
SCHWERWIEGEND: Servlet.service() for servlet action threw exception
java.lang.NullPointerException
at mdcportal.MDCPortalDAO.verifyLogin(MDCPortalDAO.java:40)
at action.Login.execute(Login.java:25)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)



Ich hab auch schon drüber nachgedacht, das es vielleicht mit der wait_timeout Variable von der MySQL Datenbank zusammenhängt
Ich hab auch schon versucht, diese wait_timeout Variable ganz niedrig zu setzen, beispielsweise auf 50 Sekunden, um zu schauen ob es daran liegt.
Ich hab dann einfach mal ein bißchen gewartet und anschließend wieder an der WebApplication angemeldet. Funktionierte einwandfrei.

 

[Oliver Gierke]

Nix MySQL, laut Stacktrace ist in deinem MDCPortalDAO in Zeile 40 ein böser Bug . Zumindest sollten in Produktivcode keine NPEs mehr fliegen . Schau wie der NullPointer zustande kommt und reproduzier das mit nem TestCase. Dann Bug fixen und sowas tritt hoffentlich nicht wieder auf .

Gruß
Ollie

 

[flo_hr]

genau an dieser Stelle wird bei mir im Quellcode ein Statement Objekt erzeugt:

Statement stmt = conn.createStatement();

Die Referenz "conn" (vom Typ Connection) wird im Konstruktor erzeugt:

conn = DriverManager.getConnection("jdbc:mysql://localhost/mdcportal", "username", "password");

Mein Problem ist, dass ich den Fehler nicht so einfach reproduzieren kann. Wie gesagt es funktioniert alles einwandfrei. Am nächsten Tag geht es dann aber auf einmal nicht mehr :-(

 

[Oliver Gierke]

Ähm, das ist doch vermutlich nicht dein Ernst, oder? Also EINE Connection aufzumachen und die dann die ganze Anwendung über offen zu halten? Sowas macht man schön auf und wieder zu oder delegiert das ganze an eine DataSource. Commons DBCP ist dein Freund

REINHAUN!

 

[flo_hr]

Ne da hast du mich ein bißchen falsch verstanden.
Ich arbeite mit dem Struts Framework und auf einer jsp Seite kann dann eine sogenannte Action ausgeführt werden.
Das heißt, wenn ich mich anmelde wird eine Action ausgeführt. In dieser Action instanziere ich dann ein Objekt von MDCPortalDAO (im Konstruktor wird die Connection aufgemacht).
Da rufe ich die Methode "verifyLogin" auf. Diese überprüft die Login-Daten mit der Datenbank. Anschließend rufe ich die Methode "disconnectDB" auf. Diese Methode schließt die Connection wieder.
Und dann leitet die Action auf eine jsp Seite weiter.

Aber mein eigentliches Problem ist leider immer noch nicht gelöst :-(

 

[Oliver Gierke]

Okay, dann musst du wohl in diesem Konstruktor SQLException catchen, weil DriverManager.getConnection diese wirft. Der catch-Block ist dann wohl weniger Sinnvoll implementiert, da deine Referenz auf conn scheinbar null bleibt.

Nochmal grundsätzlich: wenn du jedes DAO immer neu instantiierst und damit eine neue Connection aufmachst, ist das auch wiederum suboptimal. Wenn du in einem Request dann 4 oder 5 DAOs benutzt, werden da recht schnell 4 oder 5 Connections aufgemacht. Kann mir gut vorstellen, dass das eine DB irgendwann zu viel wird. Nun lass deinen Code einfach in irgendeinem Fall vergessen, die Connection wieder zu schließen. Schon hast du nen klassisches Ressourceleck. Zum anderen ist mir nicht klar, wie du auf diese Art und Weise Transaktionen handhaben willst.

Ich kann dir nur nochmal raten DataSource zu benutzen - der Hinweis zu Klasse DriverManager im JavaAPI ist sicher nicht umsonst da .

REINHAUN!

 

[flo_hr]

Ok dann hab ich jetzt noch ein bißchen was zu tun.
Schonmal vielen Dank für deine Anregungen.