jdbc connection als singleton

[ruutaiokwu]

hallo zusammen,

was haltet ihr von dieser idee:

einen wrapper für das jdbc Connection-interface erstellen (natürlich mit konkreter implementierung, welches dbms-system auch immer...), diesen als singleton einsetzen sowie die .close-methode des wrappers leer lassen...

was denkt ihr darüber? wäre ziemlich genau das gegenteil von "connection pooling"...

dann kann man das ganze auch "schön" in der destroy()-funktion des servlets verwenden:

MyConnection.getInstanceWithoutParameters().releaseConnection();

1. releaseConnection gehört nicht zum interface "Connection" ! diese methode ist von mir selbst...

2. getInstanceWithoutParameters() ist ein wenig doof als name*, der sinn davon ist, dass man die singleton-instanz OHNE PARAMETER holen kann, denn diese parameter habe ich in der destroy()-funktion des servlets nicht... -> ALS ERSTES MUSS DAS SINGLETON ABER MIT PARAMETERN INSTANZIERT WERDEN...

(* nicht dass wir wieder eine diskussion führen über gut und schlecht, was eher kontraproduktiv wäre...)


grüsse, jan

 

[maki]

Das würde imho schnell zum Falschenhals mutieren, eine Connection für mehrere User/Threads, Transaktionen sind dann wohl eher off-limit.

Was ist denn das Problem mit einem ConnectionPool?
Kenne selber nur Vorteile.

 

[ruutaiokwu]

das problem ist, dass bei unseren webanwendungen memory leaks und komische fehlermeldungen auftauchen (was mit "TimerThread0" etc...) wenn man mehrmal hintereinander ein redeployment macht, falls wir tomcat > version 6.0.20 verwenden. (das problem ist bekannt, wenn man danach googelt)

die lösungen im netz haben haben mir bisher nicht geholfen, und ich vermute dass der jdbc-treiber daran "schuld" ist...

ggf. würde sich das mit meinem hack lösen?

auf jedenfall hatte ich auch schon probleme mit dem monitoring-tool "JavaMelody", dort gab's probleme mit log4j (NoClassDefFound für NOPLoggerRepository - obwohl NOPLoggerRepository GANZ KLAR im classpath war)

und das konnte ich auch in der detroy()-funktion der servlets lösen, mit:

        LogFactory.release(Thread.currentThread().getContextClassLoader());

(+zusätzlich ENABLE_CLEAR_REFERENCES für den tomcat auf "false"...)


vielleicht ist das beim oben geschilderten problem ähnlich...? das problem ist das ich nicht wirklich beurteilen kann, was der grund dafür ist...

 

[ruutaiokwu]

jemand (?) hat auch mal behauptet, dass die meomry-leak-detection von tomcat > version 6.0.20 "buggy" sei...

 

[maki]

Ja, Tomcat hat ein paar Probleme, die sich aber IHMO auch anders lösen lassen als keinen CP mehr zu verwenden.
Speziell die "falsche" Nutzung von static ist ein Problem beim Redeploy von WebApps.
Wie sieht das eigentlich beim aktuellen Tomcat 7 aus?

 

[ruutaiokwu]

"Wie sieht das eigentlich beim aktuellen Tomcat 7 aus?"

exakt das gleiche problem! und diese tatsache stress mich vor allem! glaube nicht, dass bei uns geplant ist, tomcat 6, (höchstens 6.0.20) für die nächsten 2-3 jahre zu verwenden...

jedoch ist bei uns die idee aufgekommen, den "fetten" glassfish 3 zu verwenden, worüber ich GAR NICHT begeistert bin! (fettes, klobiges teil, wer braucht schon corba und solche sachen, und wir brauchen nicht mal ejb's und auch keine jms, sondern nur die servlet api, also wider mal "mit kanonen auf spatzen schiessen"! wenn wir eines tages ejb's verwenden würden, wäre ich eher für jboss, der würde die anforderungen VÖLLIG abdecken!)

keine ahnung, wie es sich mit glassfish verhalten würde, dessen servlet engine basiert ja nicht auf tomcat? richtig?

 

[ruutaiokwu]

scheint leider nicht wirklich was zu bringen. wenn aber zwischen den redeployments keine requests gemacht werden, dann scheint es mir so, dass das problem nicht auftaucht.

habe ca. 10 mal ein redeployment provoziert, durch einfügen von leerzeilen in die web.xml. immer alles gut gegangen.

wenn ich aber gleichzeitig den stresstest laufen lasse (ca. 20 threads mit http-request in endlosschleife), erhalte ich beim 1. redeployment diese meldung:

SCHWERWIEGEND: The web application [/SLS] registered the JDBC driver [com.micros
oft.sqlserver.jdbc.SQLServerDriver] but failed to unregister it when the web app
lication was stopped. To prevent a memory leak, the JDBC Driver has been forcibl
y unregistered.

...macht ja auch einen gewissen sinn, wenn kein request, dann auch keine db-connection!

 

[maki]

Da steht doch dass er den Treiber abgeschossen hat, damit dürfte es kein Leak geben imho.

 

[ruutaiokwu]

...ja, war mir selber nicht mehr ganz sicher, habe diese meldung schon seiten monaten nicht mehr gesehen, da ich tomcat 6.0.20 eingesetzt habe.

genau in diesem moment wo diese meldung auftaucht, steht die webapp ca. für 2 minuten still, dann ist sie wieder ansprechbar...

aber eben: passiert wie gesagt nur beim redeployment, und der prod. server wird beim (re)deployment-prozess eh heruntergefahren und wieder neu gestartet...

trotzdem versuche ich herauszufinden, an was es liegt....

 

[ruutaiokwu]

gleiches problem mit andern jdbc-treibern:

SCHWERWIEGEND: The web application [/SLS] registered the JDBC driver [com.mysql.
jdbc.Driver] but failed to unregister it when the web application was stopped. T
o prevent a memory leak, the JDBC Driver has been forcibly unregistered.
17.06.2011 15:17:43 org.apache.catalina.loader.WebappClassLoader clearReferences
Jdbc

SCHWERWIEGEND: The web application [/SLS] registered the JDBC driver [net.source
forge.jtds.jdbc.Driver] but failed to unregister it when the web application was
stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregister
ed.

 

[maki]

Lässt du die eine JNDI DataSource vom Tomcat geben oder machst du die JDBC Connection selber?
Vielleicht läuft es besser wenn der TC die Kontrolle über den Treiber bekommt.
Ansonsten hilft wohl nur ein richtiger JEE AppServer.

 

[ruutaiokwu]

die libraries befinden sich unter /WEB-INF/lib, und die connection(s) mache ich selbst...

ja, habe auch schon gelesen dass sich das in der anderen variante lösen könnte. na ja, wenn bis zuletzt nichts anderes mehr übrig bleibt...