[Java] JDBC Fragen

[Ganon]

Hi.

Ich arbeite mich zur Zeit in Java ein. Im Endeffekt geht's um eine Anwendung welche auch mehrere (ca. 3-4) Verbindungen zu einer Datenbank braucht pro Client.

Nun dachte ich das man halt Verbindungen zwischenspeichert und nicht gleich beendet. Also quasi einen Connection-Pool machen.

OK, da hab ich ihn gerade mal fix selbst gemacht und da kommt mir auch gleich ein Text unter in dem steht das so etwas in der Java Enterprise Edition schon enthalten ist. Irgendwie per JNDI, oder so.

Auf der Suche nach Informationen finde ich die aber immer nur im Bezug zu Tomcat oder JBoss.

Nun ist schlicht die Frage ob man diese auch für "normale" Anwendungen nutzen kann/sollte, oder ob das nur für Server gedacht ist? Ist das überhaupt effektiv dafür?

Auch hab ich dort gelesen (find den Link leider nicht mehr), dass das typische "DriverManager"-Zeugs wohl durch die oben genannte Art ersetzt werden soll und mit in den Standard geht. Ist da was dran?

Danke. :)

[Achill]

Bevor du dich in J2EE einarbeitest, würde ich dir http://www.hibernate.org/ empfehlen.

Kurz: Es ist ein MappingTool für Objekt-Modelle auf Relationale-Modelle und umgekehrt. Es unterstützt Conn.Pooling und Caching. Darüber hinaus kann man (wenn man keine nativ SQL-Queries macht) recht Datenbankunabhänig programmieren.

Die Deklaration des Mappings erfolgt durch XML-Dateien oder neu direkt im Java-Quellcode mittels Annotation (J2SE 5.0).

Das sollte deine Wünsche voll und ganz erfüllen und kann sowohl das Backend in J2EE Services als auch / sowie in ganz normalen J2SE Anwendungen verwendet werden.

Doku. gibt es ausreichend ... was will man also mehr ... :wink:

[HellHorse]

Hi.

Ich arbeite mich zur Zeit in Java ein. Im Endeffekt geht's um eine Anwendung welche auch mehrere (ca. 3-4) Verbindungen zu einer Datenbank braucht pro Client.

Nun dachte ich das man halt Verbindungen zwischenspeichert und nicht gleich beendet. Also quasi einen Connection-Pool machen.

OK, da hab ich ihn gerade mal fix selbst gemacht
Doofe Idee.
Gute Idee: per Treiber oder Commons DBCP

OK, da hab ich ihn gerade mal fix selbst gemacht und da kommt mir auch gleich ein Text unter in dem steht das so etwas in der Java Enterprise Edition schon enthalten ist. Irgendwie per JNDI, oder so.
JNDI erlaubt dir vereinfacht gesagt Zeugs zu finden (normalerweise im Netzwerk). Wie LDAP, bloss abstrahiert.
JNDI ist nicht Teil von Java EE, wie das auch jetzt immer heisst.
Auf der Suche nach Informationen finde ich die aber immer nur im Bezug zu Tomcat oder JBoss.
Naja, Tomcat ist ein Servlet Container und JBoss ein AppServer. Wenn du nicht weisst, was das ist, brauchst du es nicht.
Nun ist schlicht die Frage ob man diese auch für "normale" Anwendungen nutzen kann/sollte, oder ob das nur für Server gedacht ist? Ist das überhaupt effektiv dafür?
Wenn "normale" Anwendungen Desktopapplikation heisst dann nicht. Sonst siehe oben.

Auch hab ich dort gelesen (find den Link leider nicht mehr), dass das typische "DriverManager"-Zeugs wohl durch die oben genannte Art ersetzt werden soll und mit in den Standard geht. Ist da was dran?
Ja verdammt. Ich weiss nicht wie viele Links ich dazu schon gepostet habe. Such mal nach Posts von mir und DataSource.

[Ganon]

Doofe Idee.
Gute Idee: per Treiber oder Commons DBCP

Also quasi (mal fix in die PostgreSQL Doku geguckt) das für eine "gepoolte" (;)) Verbindung?


Jdbc3PoolingDataSource source = new Jdbc3PoolingDataSource();
source.setDataSourceName("A Data Source");
source.setServerName("localhost");
source.setDatabaseName("test");
source.setUser("testuser");
source.setPassword("testpassword");
source.setMaxConnections(10);

Connection con = null;
try {
con = source.getConnection();
// use connection
} catch (SQLException e) {
// log error
} finally {
if (con != null) {
try { con.close(); } catch (SQLException e) {}
}
}



JNDI erlaubt dir vereinfacht gesagt Zeugs zu finden (normalerweise im Netzwerk). Wie LDAP, bloss abstrahiert.
JNDI ist nicht Teil von Java EE, wie das auch jetzt immer heisst.

OK. Danke. :)


Naja, Tomcat ist ein Servlet Container und JBoss ein AppServer. Wenn du nicht weisst, was das ist, brauchst du es nicht.

Wie gesagt, hab ich immer nur Beispiele dafür gefunden (wenn ich nach DataSource gesucht habe). Was die beiden sind, weiß ich. Benutzen wollte ich sie so oder so nicht. ;)


Wenn "normale" Anwendungen Desktopapplikation heisst dann nicht. Sonst siehe oben.

Jups. Halt ne GUI wo viele DAUs drauf rumklicken. ;)

Ja verdammt. Ich weiss nicht wie viele Links ich dazu schon gepostet habe. Such mal nach Posts von mir und DataSource.

Ja sorry. ;)

@Achill

Danke. Mal drübergucken. ;)

[Gast]

Mir ergibt sich nicht so ganz der Sinn bei Connection Pooling auf dem Client.

[Ganon]

Na das er nicht ständig die Verbindung neu aufbauen muss, nur weil er mal kurz das Modul wechselt.

[Gast]

Na das er nicht ständig die Verbindung neu aufbauen muss, nur weil er mal kurz das Modul wechselt.

Ich kann nicht so recht an den Sinn glauben. Brauchbar wäre es, wenn du auf einem Server die Logik implementierst - die dann Connection Pooling verwendet - und die Clients diese dann remote verwenden. Natürlich bedarf es da erst einmal einer gewissen Anzahl von Clients, damit das überhaupt merkbar ist. Bei deinem Fall wird nur pro Client gepoolt, trotzdem erstellt jeder Client erst einmal die Connections. Bei vielen Clients ist dieses Design (Connection Pooling bei zwei Schichten Modell) eher nutzlos, bei wenigen Clients hingegn wird es wahrscheinlich erst gar nicht messbar sein.

[Ganon]

Ich les halt nur in vielen Tutorials das man JDBC-Objekte nicht ständig neu erzeugen soll da das richtig Zeit kostet. Man soll lieber die Verbindungen zwischenspeichern und erst bei längerem nichtgebrauch schließen.

Bei Javabuch.de wurde dazu z.B. eine LinkedQueue benutzt um die Verbindungen "offen" zu halten. Das Selbe im kleineren Maße für die Statements-Objekte.

[Shink]

So ein Pooling macht von der Performance her schon Sinn, davon abgesehen dass es ungeheuer praktisch ist:
Z.B. kann man sich erlauben, nach jeder Methode die JDBC-Connection zu schließen. Somit stellt man sicher, dass:
- Keine Verbindungen länger ungenutzt offen bleiben als gewünscht.
- Beim Aufruf der Methode eine funktionierende Connection vorhanden ist: Connection Pools wie Apache Commons DBCP überprüfen bei jeder Verbindungsanforderung transparent, ob diese noch lebt und erstellen sie gegebenfalls neu.