JDBC via Singleton

[Joptionpane]

Morgen an alle,

also gleich zum Thema:

Ich habe ein JAVA-Programm, welches auf meine Datenbank zugreifen soll. Dies hab ich mittels JDBC realisiert und hab noch den Singleton-Pattern mit eingebaut.

Habe mich nebenher im Internet natürlich schlau gemacht was geeignet wäre für solch eine Verbindung und oft wurde empfohlen ein Connection-Pool zu benutzen um solch eine Verbindung aufzubauen.

Nun das ganze ist ein Projekt im Studium, das Programm ist fertig und läuft einwandfrei. Natürlich werd ich das Projekt nicht Online stellen (Wörterbuch/Dictionary), da es simpel erstellt wurde und niemals den großen Seiten eine Konkurrenz darstellen würde.

Jedoch würde ich gern wissen, warum der Singleton-Pattern nicht so geeignet wäre?
Würde es ggf. zu Komplikationen führen wenn ich bspw. die Seite Online stelle und mehrere Leute sich auf der Seite registrieren und anmelden, sprich Multi-Threaded?
Oder hab ich da was falsch verstanden? Über eine kleine Erläuterung bezüglich dieses Anwendungsbeispieles würde ich mich freuen

Viele Grüße
JOption

 

[Spacerat]

Also das DataSource-Objekt kann schon ein Singleton sein, da spricht nichts dagegen. Nur sollte dessen "getConnection()"-Methoden nicht immer dieselbe Instanz einer Verbindung liefern, das wäre fatal. Ausserdem müssten diese Methoden dann wohl auch synchronisiert werden.

 

[Joptionpane]

hmm bei mir siehts jetzt so aus, würde des beim online stellen ohne Probleme funktionieren mit Mitgliedern?(rein theoretisch jetzt)

public class ConnectionFactory {

	private static Connection con = null;
	
    public static Connection createConnection() {
     	
    	if(con == null){
        	 	
        	String localUrl = "jdbc:mysql://localhost:3306/";
        	String Url = localUrl;
        	String db = "dab"; 
            String user = "root"; 
            String pw = "";
            	
    	    Connection con = null;
            try {
              
                con = DriverManager.getConnection(Url + db, user, pw);
                con.setAutoCommit(false);

            } catch (Exception e) {
                System.out.println(e.getMessage());
                e.printStackTrace();
                System.out.println("Connection Error");
            }

            return con;   		
    	}
    	else return con;

    }


}

 

[utnovetur]

Hallo,

dir ist klar, dass du zwei Variablen mit Namen con hast - ein static member (das immer null ist) und eine lokale Variable.
Bei jedem Aufruf erzeugst du also eine neue Connection, die du dann hoffentlich auch schließt.

 

[Joptionpane]

Hallo,

dir ist klar, dass du zwei Variablen mit Namen con hast - ein static member (das immer null ist) und eine lokale Variable.
Bei jedem Aufruf erzeugst du also eine neue Connection, die du dann hoffentlich auch schließt.

mein fehler, das war eigentlich kommentiert gewesen, hier der richtige:

public class ConnectionFactory {
 
    private static Connection con = null;
    
    public static Connection createConnection() {
        
        if(con == null){
                
            String localUrl = "jdbc:mysql://localhost:3306/";
            String Url = localUrl;
            String db = "dab"; 
            String user = "root"; 
            String pw = "";
                
            // Connection con = null;
            try {
              
                con = DriverManager.getConnection(Url + db, user, pw);
                con.setAutoCommit(false);
 
            } catch (Exception e) {
                System.out.println(e.getMessage());
                e.printStackTrace();
                System.out.println("Connection Error");
            }
 
            return con;         
        }
        else return con;
 
    }
 
}

 

[Spacerat]

Das ist genau das, was ich meinte, was nicht geht. Du machst hier aus den Verbindungen Singletons. Man kann Verbindungen zwar permanent offen halten, aber was ist, wenn eine solche dann mal ungewollt unterbrochen wird? Du müsstest dann die komplette Anwendung neu starten.
Ausserdem instanziert man Singletons synchronisiert, damit nicht mehrere Threads gleichzeitig verschiedene Objekte erzeugen können.

 

[Joptionpane]

Das ist genau das, was ich meinte, was nicht geht. Du machst hier aus den Verbindungen Singletons. Man kann Verbindungen zwar permanent offen halten, aber was ist, wenn eine solche dann mal ungewollt unterbrochen wird? Du müsstest dann die komplette Anwendung neu starten.
Ausserdem instanziert man Singletons synchronisiert, damit nicht mehrere Threads gleichzeitig verschiedene Objekte erzeugen können.

Hm ja hab darüber auch einiges im Internet gelesen, dass man es synchronisieren soll, eben damit nicht mehrere Threads gleichzeitig versch. Objekte erzeugen sollen/können. Jedoch dacht ich mir, dass dies Irrelevant ist für dieses Projekt, da es imho nicht möglich ist, dass die Verbindung unterbrochen wird(durch was auch), da dies ja alles Offline hier geschieht.
Hab jetzt halt am Montag die Präsentation über dieses Projekt wo ich ca. 7-8 Minuten erzählen muss wie ich JDBC via Singleton implementiert habe, will jetzt durch diese Fragerei hier, mögliche Fragen vom Prüfer sicher entgegenwirken.
Hab jetzt als Begründung vor zu erläutern, dass ich den Singleton Pattern drin habe, da alles Offline geschieht und nur wir die Administratoren auf die Datenbank zugriff haben, womit Multi-Threading eigtl. ausgeschlossen ist. Dennoch siehts für mich schwer aus, 7-8 Minuten über solch ein kleinen Code zu reden^^

 

[Spacerat]

Multithreading ist normalerweise niemals ausgeschlossen. Deswegen solltest du es evtl. so begründen, dass es für das Projekt so genügt und weitere Absicherungen gegen Verbindungsabbruch oder Mehrfachinstanzierung den Zeitrahmen gesprengt hätten. Die 7-8 Minuten bekämst ja evtl. damit voll, über diese Problematiken zu reden. Dann vergisst der Prüfer evtl. seine diesbezüglichen Fragen.

 

[Joptionpane]

Ok, alles klar, vielen dank

Werd noch bis Montag den Thread hier offen lassen, falls ich noch ne Frage habe

Viele Grüße

 

[turtle]

Singleton Pattern drin habe, da alles Offline geschieht und nur wir die Administratoren auf die Datenbank zugriff haben, womit Multi-Threading eigtl. ausgeschlossen ist.

Diesen Zusammenhang würde ich NICHT erwähnen. Das Eine (offline) hat nichts mit der Technik Singleton zu tun.

Es kann ja passieren, dass sich zwei Administratoren auch offline bei deinem Programm anmelden, oder?

Aber die Verbindung zur DB sollte es nur einmal geben, da ja das was Admin1 macht auch von Admin2 gesehen werden soll. Daher sind hier auch konkurierende Zugriffe möglich und sinnvoll. Wie schon richtig beschrieben wurde, werden Verbindungen zu einer DB üblicherweise gepoolt und sind nur kurz offen und werden danach an den Pool zurückgegeben. Danach wird eine weitere Aktion, gleicher oder anderer Benutzer, wieder eine Connection vom Pool anfordern, etwas tun und danach wieder an den Pool geben.

Also müssen die Aktionen, die auf der DB agieren, synchronisiert werden, damit nicht ein anderer Thread da irgendwie reinfunkt.

Wenn ich mir das so überlege, würde ich das Singleton-Pattern rausnehmen und stattdessen einen static-Intitialisier schreiben, der den Pool instanziert. Dieser wird nur einmal aufegrufen und zwar wenn die Klasse von der JVM geladen wird.

Alle anderen Methoden arbeiten dann mit dem Pool. Damit gehst Du jede Diskussion aus dem Weg, die irgendwie mit der Synchonisation eines Singleton in Multi-threaded Umgebungen zu tun hat. Und das ist nicht ohne, denn die üblichen Implementierungen eines Singleton, die man so findet, sind nicht threadsafe!

 

[JohannisderKaeufer]

Das Singleton, wie es hier implementiert wurde, hat noch einen weiteren Schwachpunkt.


Wie soll das ganze getestet werden?

"dab" ist deine Produktionsdatenbank, da sind normalerweise "wertvolle" Daten drin.

Wenn man testet, sofern man testet, möchte man eine extra Datenbank haben um nichts böses mit seinen "wertvollen" anzustellen, was man später bitterböse bereut.


Dependency Injection ist hier eine mögliche Lösung. Damit kann man sich an den Stellen, an denen man eine Connection braucht eine Connection liefern lassen. Und in Test-Szenarien läßt man sich eben eine Connection zu einer Testdatenbank liefern. DI Provider wie Guice, Spring oder CDI können das IMHO ganz gut.

Bei einem selbstimplementierten Singleton verbaut man sich diesen weg, da dort die Connections aktiv geholt werden und somit dann auf die Produktivdatenbank zugegriffen wird.

 

[Joptionpane]

Wie gesagt, es ging ja nur um ein Projekt für eine Vorlesung/Veranstaltung. Jetzt ist die Prüfung vorbei und alles lief gut, wurde eigtl. garnicht auf das Thema eingegangen. Den Professor hat es viel mehr interessiert, was wir in PHP programmiert haben von daher alles easy

Danke an alle für die Hilfe.

Closed

 

[Spacerat]

Den Professor hat es viel mehr interessiert, was wir in PHP programmiert haben...

Antwort Schüler: NICHTS!
Reaktion Professor: Sehr gut. Eins. setzen.
:lol: