Ressourcenverbrauch Connection Open/Close

[schnitt_tt]

Hallo

bei Programmen mit DB wird man ständig daraufhingewiesen, dass man die Connection schliesen sollte wenn man sie nicht mehr benötigt. Angeblich würde eine Connection viel "Resourcen brauchen".

Da ich primär mit embedded Datenbanken zutun habe, habe ich versucht etwas mehr Licht für diesen Anwendungsfall ins Dunkel zu bringen:

(DERBY DB) Test wie lange das Öffnen und Schliesen der Connection benötigt via:

    public void checkOpenCLoseConnection(int anzahlLoops)
    {

        for ( int i = 0; i < anzahlLoops; i++)
        {
            try
            {
                Connection test_con1;
                test_con1 = DriverManager.getConnection( Datenbank.databaseLocation);
                test_con1.setAutoCommit( false );
                test_con1.close();
                test_con1 = null;
            } catch (SQLException e) {
                e.printStackTrace();
            }
        }
    }

das Ergebniss:

Loops              Minuten        Sekunden          Milli               Mikro                      Nano 
           1               0              0             1                1.136                  1.136.881 
         100               0              0            85               85.957                 85.957.969 
        1000               0              0           622              622.972                622.972.138 
       10000               0              2         2.205            2.205.511              2.205.511.851 
      100000               0              6         6.961            6.961.976              6.961.976.411

-> 1000x öffnen / schliesen benötigt ca `ne halbe sekunde, das hört sich für mich nicht wirklich viel an. Wenn ich mir überlege das eine Transaktion ja grundsätzlich so aussieht

1) open connection
2) create statement
3) execute
4) mach was mit dem ResultSet
5) close ResultSet / close Statement
6) close connection

würde ich kühn :lol:behaupten das Öffnen und Schliesen einer Verbindung fällt da Laufzeitmäßig nicht ins Gewicht. Die Speicherseite kann ich leider nicht überprüfen, hierfür werde ich mich wohl mit einem Profiler auseinandersetzen müßen.

Falls das Open/Close einer Verbindung nicht zum "Speicher zu müllen" führt könnte man doch folgendes festhalten: (alles bezogen auf embedded Datebanken in Desktop Applicationen)

a) jeder Thread der Application bekommt seine eigene Connection und kümmert sich um diesen
somit ist der Fallstrick wer verwendet was beim Multithreading schonmal gelöst.

b) Verwendung eines Connections-pool "spart" lediglich Tipparbeit, bringt eventuell
eine Fremdbibliothek ins Spiel (die xte lib *Hurra), hat laufzeittechnisch keine Vorteile
???? warum sollte man den Pool verwenden ????


c) man könnte auch so 10 Connections permanent anlegen, die lediglich für bestimmte Aufgaben verwendet werden dürfen.
Thread1 = con1 (die Langläufer prozesse)
Thread2 = con2 (adhoc abfragen)
.....
aber nur um sich das öffnen / schliesen zu sparen -> imho konzeptioneller Overkill



wie seht Ihr das bzw hab ich einen Denkfehler bzw denke ich da etwas zu kurzfristig?
steck die Crux im Speicherverbrauch ?

 

[turtle]

wie seht Ihr das bzw hab ich einen Denkfehler bzw denke ich da etwas zu kurzfristig?

Ich denke schon, denn Du schliesst von Deinem Beispiel einer embedded DB auf eine allgemeine Sache, die so leider nicht stimmt.

"Normalerweise" laufen RDBMS im ServerModus auf teilweise sehr, sehr leistungsfähiger Hardware. Dieses können über JDBC angesprochen werden, benötigen dafür aber einen/mehrere Netzwerkzugriffe. Dieser Verbindungsaufbau dauert bei vielen DB um Grössenordnungen länger als die eigentliche SQL-Operation. Daher sollte man dieses verhindern und auf bereits aufgebaute Verbindungen (gepoolte Connection) zurückgreifen. Dein Beispiel mit einer embedded DB ist da kein guter Test weil ja überhaupt kein Netzwerkzugriff gemacht wird und die Daten in derselben JVM sind.

Wenn Dir das Einbinden einer weiteren Bibliothek nicht gefällt, kannst Du ja auch Deinen eigenen Connection-Pool schreiben. Aber dann wirst Du bemerken, dass da Anforderungen reinkommen, an die Du wahrscheinlich zu Anfang nicht gedacht hast. Zum Beispiel wie ist sichhergestellt, dass die Connection noch valide ist und benutzt werden kann? Alles in allem vermeiden die meisten Leute den Aufwand für die Erstellung eines eigenen Pools.

 

[ARadauer]

hab mirs jetzt im detail nicht durchgelesen aber..

eine Fremdbibliothek ins Spiel (die xte lib *Hurra), hat laufzeittechnisch keine Vorteile

ich würd das effiziente poolen von teuren datenbank verbindungen (und das sind sie wirklich) schon als vorteil bezeichnen ...

 

[schnitt]

@turtle & ARadauer

ich beziehe mich bewußt nur auf Embedded, da mir das "EE in Java" aktuell egal ist !(Geschäftsanwendungen / WEB haben ihre eigenen Anforderungen (Netz, "Massen-User Request" etc).

Du ja auch Deinen eigenen Connection-Pool schreiben.

möchte ich nicht, aber warum sollte ich den verwenden ??? ich kann da noch keine Vorteile erkennen (lassen wir mal: "man wird später im Geschäftsleben eh damit konfrontiert" außen vor).

 

[turtle]

warum sollte ich den verwenden ???

Habe ich schon beantwortet.
[TIPP]Dieser Verbindungsaufbau dauert bei vielen DB um Grössenordnungen länger als die eigentliche SQL-Operation.[/TIPP]

 

[SlaterB]

@schnitt_tt
was ist im Moment eigentlich konkret deine Aussage?

> bei Programmen mit DB wird man ständig daraufhingewiesen, dass man die Connection schliesen sollte
> wenn man sie nicht mehr benötigt. Angeblich würde eine Connection viel "Resourcen brauchen".

dieser Satz spricht sich also fürs Schließen aus, in der Interpretation, dass eine Connection nicht lange ungenutzt offen bleiben sollte,
ich persönlich kann mir da auch Verwaltungsaufwand für die DB vorstellen, welcher in Java noch schlechter zu messen ist,

dein Test jedenfalls misst, dass das Schließen rasend schnell geht,
ist das nicht eine Bestätigung dieses Hinweises auf 'schnelles Schließen'?

wogegen könntest du dich richten, doch allein gegen das Langzeit-Offenhalten von Connections?,
dagegen arbeiten ConnectionPools auch teilweise, sind als Cache zwar sicher nicht Dauer-Öffner,
werden aber jedenfalls auch nicht allzu lange zuschauen wie offene Connections rosten

 

[schnitt_tt]

@turtel

Habe ich schon beantwortet.

aehm ... ich beziehe mich lediglich auf das arbeiten mit einer embedded DB. -> das millisekunden bei einer Geschäftsanwendung und massen von Usern eine Rolle spielen kann ich mir vorstellen ... dein Hinweis bezog sich meiner Ansicht nach auf "Geschäftsanwendungen" bzw das Umfeld in dem sich Geschäftsanwendungen tummeln.


@SlaterB

was ist im Moment eigentlich konkret deine Aussage?

mein test sagt für mich aus, das das öffnen und schliesen einer Connection auf meinem System bei einer Derby DB aus meiner Sicht sehr schnell geht und das Argument "hoher Resourcenverbrauch" aus meiner Sicht somit hinfällig ist .... (wobei der Aspekt "Arbeitspeicher" nicht betrachtet wurde).

wogegen könntest du dich richten, doch allein gegen das Langzeit-Offenhalten von Connections?,
dagegen arbeiten ConnectionPools auch teilweise, sind als Cache zwar sicher nicht Dauer-Öffner,
werden aber jedenfalls auch nicht allzu lange zuschauen wie offene Connections rosten

*gruebel ... das hab ich jetzt nicht ganz verstanden ..

Connection-Pools halten, soweit ich das verstanden habe, ein paar Connections vor um das erstellen und managen dieser Verbindungen so gering wie möglich zu halten. Das Überwachen einer Connection ob da ein SQL rangerauscht kommt oder nicht, kostet ja auch Zeit. Je mehr Verbindungen von der DB zu managen sind (überwachen) desto weniger DB-Resource stehen für das arbeiten der SQL`s zur Verfügung.... somit könnte ich mir zumindest die allgemeine Aussage "Connections sind Resourcenhungrig" erklären.

aber was bringt mir das bei einer Embedded Datenbank ????? da gibt`s vielleicht parallel 3 threads die auf die DB zugreifen ... dann passiert 10 Minuten nix, weil der User mit anderen Dingen beschäftigt ist ... hier mal wieder ein DB Zugriff .... das sind doch komplett andere Anforderung wie bei WEB / Geschäftsanwendungen ....

nur weil "jeder" sagt eine Connection ist teuer, soll man sich Connection-Pooling beschäftigen, in eine weitere Abhängikeit zu einem Fremdprodukt begeben, obwohl dies vielleicht für den "Embedded" Fall nicht notwendig ist ???

 

[silentkill_8989]

Nun mal ne ganz blöde Frage @ TE:

Du beharrst doch sowieso darauf das du Recht hast, warum diskutiert ihr hier dann überhaupt? Sicherlich is bei einer Embedded-DB wo so n paar SQL anfragen kommen ziemlich egal wieviele Connections offen sind. Das is auch bei einer Remote-DB relativ egal, so lange wie man halt nicht "viel" Verkehr hat.

 

[markus_cheers]

Hey Leute!

Ich hätte auch mal eine Frage zum Ressourcenverbrauch bei einer Connection mit Java über JDBC. Ich hab ein kleines Verwaltungsprogramm geschrieben das mehrmals die Methoden "Datenbanktreiber laden" und "Connection aufbauen" verwendet.

So wie ich das jetzt verstanden hab, wäre es effizient einen Connection-Pool über das Einbinden einer weiteren Bibliothek zu nutzen, oder? Die beiden anderen Varianten wären ja entweder immer wieder eine Verbindung aufzubauen und wieder zu schließen. Oder die Verbindungen bestehen zu lassen, ohne immer wieder eine neue Verbindung zu nutzen. Beide Möglichkeiten würden viel Resourcen brauchen!

Ich hoffe es ist in Ordnung das ich keinen neuen Thread aufgemacht hab. Aber das hat so gut hierzu gepasst!

Gruß Markus

 

[SlaterB]

alles je nach Umständen richtig was du sagst, auch wenn das in diesem Thread widerlegt werden soll

ich möchte nur anmerken, dass in einem einfachen Programm für alle Varianten genug Ressourcen da sein sollten,
darum musst du dir eigentlich keinen Kopf machen, lege eine Connection dauerhaft an und gut,

falls du wider Erwarten mit Problemen wie Verbindungsabbruch kämpfen musst, kannst du immer noch schauen,
ob die anderen Varianten besser sind,
aber falls du ConnectionPool nicht als unnötige Arbeit ansiehts, ist das langfristig sicher die beste Lösung, ja

 

[markus_cheers]

alles je nach Umständen richtig was du sagst, auch wenn das in diesem Thread widerlegt werden soll

ich möchte nur anmerken, dass in einem einfachen Programm für alle Varianten genug Ressourcen da sein sollten,
darum musst du dir eigentlich keinen Kopf machen, lege eine Connection dauerhaft an und gut,

falls du wider Erwarten mit Problemen wie Verbindungsabbruch kämpfen musst, kannst du immer noch schauen,
ob die anderen Varianten besser sind,
aber falls du ConnectionPool nicht als unnötige Arbeit ansiehts, ist das langfristig sicher die beste Lösung, ja

Wie lege ich denn eine dauerhafte Verbindung an? Bisher hab ich immer wenn benötigt die beiden Methoden aufgerufen, um den Treiber zu laden und eine Verbindung aufzubauen.

//Treiber wird geladen
GUI.methoden.startdriver(DAO.driver);
        
//Verbindung zur Datenbank
Connection conn = GUI.methoden.getConnection(DAO.url, DAO.user, DAO.passwort);

 

[SlaterB]

diese conn in einer statische Variable, schon für alle immer vergügbar, ähnlich System.out und andere,
hat viele Haken, z.B. schon zwei Threads gleichzeitig, aber für einfache kleine Programme denkbar