Connection schließen oder speichern? Performance Frage

[xX_QueAnw_Xx]

Hi. Ich habe ein Programm das sehr, sehr häufig, fast permanent auf meine Datenbank zugreifen musse. Die Datenbank Verbindung erstelle ich mit einer staatischen Klasse (Connect) welche die Verbindung als private Attribut speicher, siehe UML:


Allerdings ist das ganze relativ langsam. Das könnte jetzt daran liegen das ich einen Kostenlosen MySQL hoster benutze oder aber daran das es schlicht weg schlecht programmiert ist.

Mein Frage. Sollte ich die Verbindung immer wenn ich sie brauche neu erstellen und am Ende wieder schließen oder ist das so in Ordnung mit Zentraler speicherung der verbindung.
+Wie sollte ich mit den Create Statements umgehen?

Eine normale Abfrage sieht bei mir zurzeit so aus:

Erzeugen der Verbindung

public class Main {
    static Login start;
    public static void main(String[] args) throws SQLException {
        Connect.makeConnection("www.******.net", "jtask", "xX_QueAnw_Xx", "******");
        showLogin();
    }
//....

Abfrage:

           String query="SELECT pw FROM user WHERE uname=\'"+user.trim()+"\' limit 1";
           ResultSet rs=Connect.getConnect().createStatement().executeQuery(query);
           if (rs.next()){
              if(rs.getString(1).trim().equals(pw.trim()))
                  correct=true;
           }
           rs.close();

Verbesserungsvorschläge? Gibt es für soetwas Konventionen.

 

[Gast2]

Wenn es irgendgeht würde ich immer ConnectionPooling verwenden. Für jede Anfrage eine Verbindung aufbauen und wieder schließen ist sehr uneffizient.

Verbesserungvorschläge:
1) Benutze ConnectionPooling
2) Statische Connection Klasse ist als Design nicht wirklich schön, siehe 1)
3) Verwende PreparedStatements
4) Niemals Passwörter in der DB speichern! Nur die Hashes

Das es sehr langsam ist würde ich jetzt mal auf den kostenlosen Mysql hoster schieben. Die kostenloasen Service Provider werden dir nicht grade eine qualitativ gute Infrastruktur bieten.

Probier es doch zum Entwicklen erstmal bei dir lokal aus.

 

[MrWhite]

4) Niemals Passwörter in der DB speichern! Nur die Hashes.

Und die am besten noch obfuscaten, dann sind deine User sogar vor Rainbow-Tables geschützt.

 

[Gast2]

Naja, mit einem guten Hash-Algorithm und vernünftigen Salts sehe ich da kein Problem.

 

[Ebenius]

Hinweis am Rande: Es hängt immer vom JDBC-Treiber ab, ob man auf die Nase fällt. Aber auch die Statements sollten nach dem ResultSet geschlossen werden.

Ebenius

 

[xX_QueAnw_Xx]

Wenn es irgendgeht würde ich immer ConnectionPooling verwenden. Für jede Anfrage eine Verbindung aufbauen und wieder schließen ist sehr uneffizient.

Verbesserungvorschläge:
1) Benutze ConnectionPooling
2) Statische Connection Klasse ist als Design nicht wirklich schön, siehe 1)
3) Verwende PreparedStatements
4) Niemals Passwörter in der DB speichern! Nur die Hashes

Das es sehr langsam ist würde ich jetzt mal auf den kostenlosen Mysql hoster schieben. Die kostenloasen Service Provider werden dir nicht grade eine qualitativ gute Infrastruktur bieten.

Probier es doch zum Entwicklen erstmal bei dir lokal aus.

1. / 2. Ok danke das werde ich mir aufjedenfall anschauen auch wenn ich jetzt noch keine Vorstellung davon habe was es ist.

Gleiches gilt für 3.

zu 4. Wenn dieses Programm zum effektiven einsatz kommen würde, würde ich keine Plain PWs speichern, das weiß ich, aber es dient mehr zu Test zwecken und als Hobby entwicklung um zu schauenw as machbar ist und was alles Möglich ist.

Also eine gängige Konvention gibt es sonst dazu nicht? Wie gesagt bin gespannt auf das Connection Pooling

Hinweis am Rande: Es hängt immer vom JDBC-Treiber ab, ob man auf die Nase fällt. Aber auch die Statements sollten nach dem ResultSet geschlossen werden.

Ebenius

Ok mit der von mir beschriebenen Variante sollte ich natürlich auch X statement Objekte auf machen und niemals schließen. Hier ist halt die Frage Wann und wie effektiv arbeitet hier der Garbage Collector.

mfG

 

[Gast2]

Die best practice ist halt einfach einen ConnectionPool zu benutzen. Der kümmert sich selbstständig darum Verbindungen zu der Datenbank aufzubauen und abzubauen. Wenn du in deiner Applikation dann eine Verbindung brauchst fragst du die beim Pool an und bekommst eine Verbindung. Wenn du mit der Abfrage fertig bist "entlässt du die Verbindung" zurück in den Pool.

In der Regel sollte ein Pool dann so konfiguriert sein das er immer ein paar aktive Verbindungen zu der Datenbank bereithält.

 

[MrWhite]

Naja, mit einem guten Hash-Algorithm und vernünftigen Salts sehe ich da kein Problem.

Sicher ist sicher. So können auch Schwachstellen im Algorithmus wie sie z.B. in MD5 gefunden wurden nicht so einfach ausgenutzt werden. Ein gesalzenes Hash das obfuscated wurde ist so ziemlich die höchste Sicherheitsstufe, die man auf diesem Wege erreichen kann.