Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.java > #13137

Re: Thread-safe singleton

Show all headers | View raw

Am 06.09.2017 um 23:27 schrieb Patrick Roemer:
> Responding to Volker Borchert:
>> Klassisches kaputtes Double Checked Locking. Tante Gurgel sollte das
>> genauso klassische Paper dazu (von IIRC Doug Lea oder William Pugh)
>> zutage fördern. 

> Klassisches DCL ist mit dem "neuen" Memory Model und volatile nicht mehr
> kaputt - was im klassischen Paper auch frühzeitig nachgetragen wurde.

Ich nehme an, ihr sprecht von
https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.

>> Kaufe oder leihe Dir "Effective Java" und lies im
>> einschlägigen Kapitel nach, wie man Singletons richtig macht.

Werde ich. Ist es das von Joshua Bloch?

> Der Code ist nicht klassisch kaputt sondern sehr individualistisch fritte.

Danke :-)

> Und zuletzt sollte man hier nicht unbedingt nachschlagen, wie man
> Singletons "richtig" macht, sondern zunächst mal kontemplieren, ob man
> überhaupt eins will. Meine Vermutung: Nö.

Bin mir immer noch nicht sicher. Plan ist inzwischen folgender:

Es gibt eine Klasse, die die eigentliche Datenbank repräsentiert, eine,
die weiß, in welchem Format die Daten aus dem Internet ankommen, und
eine, die das Format kennt, in dem die Daten aus der Datenbank
geschrieben werden sollen. Dazu eine main-Methode; ob die in einer
eigenen Klasse ist oder an eine der anderen Klassen angehängt wird, ist
vermutlich unerheblich. Aber es ist eine Aufgabe, die nicht speziell an
eine der anderen Klassen gekoppelt ist, also bekommt sie erstmal ihre
eigene Klasse.

main() erzeugt (inzwischen) ein Objekt der Datenbankklasse. main() liest
die Zugangsdaten aus einer ini4j-Datei und übergibt sie im Konstruktor.
Die Importer- und Exporter-Klassen brauchen nach aktuellem Stand der
Dinge kein Objekt; es reicht aus, wenn die import- bzw. export-Methode
statisch ist. main() übergibt das Datenbankobjekt, damit die beiden
anderen wissen, an wen sie ihre geparsten Daten zu übergeben haben.

Die Idee war, dass das Datenbankobjekt genau einmal eine Connection
herstellt. Weitere Methoden erzeugen das gerade passende
(Prepared)Statement. Der Importer führt verschiedene for-each-Schleifen
aus, in der jeweils eine Zeile des Input-Files geparst wird und die
passende Methode mit dem Datensatz als Argument ausgeführt wird. Der
Exporter holt Datensatz für Datensatz ab, solange noch Daten existieren.
Am Ende von main() wird dann ein close() aufgerufen, das
Connection.close() ausführt. Es geht um je eine halbe Million
Datensätze, da wäre der Aufwand, für jeden Datensatz eine neue
Connection und ein neues Statement zu erstellen und wieder zu schließen,
ETWAS groß.

Nachdem ich sicher sein kann, dass immer nur genau eine Datenbank
gleichzeitig geöffnet ist, war die erste Idee, die Connection als
statisches Singleton anzulegen. Ich habe gelernt, dass die Idee
zumindest falsch umgesetzt war. Die Thread-Sicherheit war ein Symptom,
dass etwas nicht stimmt, auch wenn die geplante Anwendung
single-threaded ist und Multithreading nicht geplant ist. Jedenfalls im
Moment nicht, aber das könnte sich jederzeit ändern.

Bleibt die Frage, wie ich das, was ich will, richtig umsetze ...

lg
QNo

Back to de.comp.lang.java | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Thread-safe singleton "Christian H. Kuhn" <qno-news@qno.de> - 2017-09-06 18:29 +0200
  Re: Thread-safe singleton Patrick Roemer <sangamon@netcologne.de> - 2017-09-06 21:06 +0200
  Re: Thread-safe singleton v_borchert@despammed.com (Volker Borchert) - 2017-09-06 20:02 +0000
    Re: Thread-safe singleton Patrick Roemer <sangamon@netcologne.de> - 2017-09-06 23:27 +0200
      Re: Thread-safe singleton v_borchert@despammed.com (Volker Borchert) - 2017-09-07 16:45 +0000
      Re: Thread-safe singleton "Christian H. Kuhn" <qno-news@qno.de> - 2017-09-11 01:08 +0200
        Re: Thread-safe singleton Patrick Roemer <sangamon@netcologne.de> - 2017-09-11 18:14 +0200
  Re: Thread-safe singleton Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-09-06 23:26 +0200
    Re: Thread-safe singleton Claus Reibenstein <4spamersonly@kabelmail.de> - 2017-09-10 13:52 +0200

csiph-web