Statische Klasse => Flaschenhals?

[Fohnbit]

Hallo!

Es laufen von diversen Klassen ca. 500-600 Instanzen.
Ziel ist es in eine Sqlite DB zuschreiben. Damit nicht jede eine Verbindung dahin aufbaut und einige zentrale DB Operationen Zeitgesteuert durchgeführt werden müssen, würde ich gerne diese Klasse als statisch deklarieren und bei meinen ganzen Projekten hinzufügen.

Statisch, wenn ich es richtig verstehe, heißt die Klasse ist nur 1x im Speicher, auch wenn ich diese in verschiedenen anderen Klassen nutze und in Eclipse im Projekt hinzugefügt habe, richtig?

Ich frage ich aber was passiert, wenn die Methode "writeData" (schreibt die Daten in die DB) alle 500 fast zur selben Zeit aufrufen und Daten zum schreiben übergeben.

Ist das eine sichere Methode? Wenn die Klassen die die statische Methode "writeData" aufrufen einige Millisekungen blockieren ist das kein Problem.

 

[InfectedBytes]

was meinst du mit "fast zur selben Zeit"?
Wenn du mit mehreren Threads arbeitest, welche zeitgleich auf deine statische Methode zugreifen können, wird es mit ziemlicher Sicherheit zu Problemen kommen. In dem Fall solltest du die Methode synchronisieren. Dies geht z.B. mit dem synchronized Schlüsselwort.

Wenn du aber nur einen Thread hast, kann es natürlich zu keinen Komplikationen zwischen den Aufrufen kommen.

 

[Fohnbit]

Hallo!

Ja, es werden mehrere Threads auf dieselbe Methode zugreifen. Das wird immer zu vollen Stunde sein und daher alle fast zeitgleich.
Also wenn ich "synchronized" nutze, habe ich das Problem nicht?
Gibt es auch einen Nachteil dabei? Denn warum nicht gleich alle statischen Methoden mit "synchronized" ausführen?

 

[Thallius]

Natürlich gibt es einen Nachteil. Du verlierst alle Vorteile die du durch das Nutzen von mehreren Threads bekommen hast. Du könntest dann genausogut alle Deine Threads weglassen und einfach 500x nacheinander die gleiche Methode aufrufen.

Das Problem wird sich aber so oder so nicht lösen lassen wenn alle 500 Threads gleichzieitig schreibend auf die gleiche DB zugreifen sollen. Das wird auf jeden Fall einfach nur langsam werden.

Gruß

Claus

 

[Fohnbit]

Hallo Claus!

Ok, dann wäre es klug einen Producer/Consumer zu nutzen? Dann könnten alle Threads deren Werte in die Queue legen und der Producer hat dann eigentich eine Stunde Zeit, diese in die DB zu schreiben.

 

[Tobse]

Hallo Claus!

Ok, dann wäre es klug einen Producer/Consumer zu nutzen? Dann könnten alle Threads deren Werte in die Queue legen und der Producer hat dann eigentich eine Stunde Zeit, diese in die DB zu schreiben.

Bingo.

Je nachdem, welchen Treiber du für SQLite benutzt kann der das evtl schon. Zumindest große RDS machen das intern: wenn viele Schreibzugriffe passieren, werden die im Ram gespeichert (damit unmittelbar darauf folgende Lesezugriffe keine Inkonsistenzen verursachen) und dann wird das ganze sauber geordnet und effizient auf die Festplatte geschrieben.

 

[ARadauer]

Hier über eine statisch Klasse die Verbindung zur Datenbank für die Anwendung zur Verfügung zu stellten halte ich für einen Fehler.

Das kann man schnell mal für einen kleinen Test machen, aber für eine Anwendung mit Klassen 600würde ich echt etwas „professionelleres“ machen.

Ich würde mir Spring ansehen. Du suchst hier Lösungen für Probleme für die sich schon sehr schlaue Leute den Kopf zerbrochen haben. Im Grunde brauchst du eine Resource in deinen Klassen. Die Klassen sollen sich aber nicht um das Verwalten der Resource kümmern… das soll jemand anders machen IOC (inversion of control). Du hast Abhängigkeiten zur Datenbank und das soll von außen über einen Container Mechanismus in deine Objekte rein gepackt werden DI (Dependency Injection). Das ist genau der Anwendungsfall von Spring.

Wenn du hier anfängst mit synchronized zu arbeiten, wirst du noch auf ganz andere Probleme stoßen. Ich würde mir das synchronized auf jeden Fall sparen. Du musst halt aufpassen, dass sich die Threads keine Variablen teilen… was du aber wahrscheinlich willst, da du ja die vermutlich die Connection zur Datenbank cachen willst. Wo wir beim Thema Connection pooling sind… auch ein Problem dass schon jemand gelöst hat. Mit Spring kein Probem…

http://docs.spring.io/spring/docs/current/spring-framework-reference/html/jdbc.html

 

[Fohnbit]

Ich nutze sqlite-jdbc-3.8.10.1.jar

Der Ablauf wäre dann wie folgt?:
Ich erstelle ein neues Projekt mit dem DatabaseWorker.

In den Projekten die in die DB schreiben erstellen ich:

  public static final DatabaseBackroundWorker DATABASE_BACKGROUND_WORKER = new DatabaseBackroundWorker();

static weil es diesen nur 1x geben soll, final weil wenn erzeugt, er nicht wieder veränderbar ist.

In der DatabaseWorker Klasse:

1. Im Constructor die Datenbank Verbindung herstellen und die Tabellen prüfen (da statisch und final wird dieser nur 1x aufgerufen?)
2. Im Constructor mittels ScheduledExecutorService einen zyklischen Timer für allgemeine Datenbank Operationen definieren und starten

Die Klassen übergeben dann jede Stunde mit:
DATABASE_BACKGROUND_WORKER.putInQueue(msg);
die neuen Messages in den Producer.

Der Consumer startet sobald eine neue Message in der Queue ist, wartet dann noch 10sek (damit andere Klassen noch Infos in die Queue legen können) und gibt dann die Queue an den DatabaseBackgroundWorker zurück, der die Daten abarbeitet.

 

[Fohnbit]

Hier über eine statisch Klasse die Verbindung zur Datenbank für die Anwendung zur Verfügung zu stellten halte ich für einen Fehler.

Das kann man schnell mal für einen kleinen Test machen, aber für eine Anwendung mit Klassen 600würde ich echt etwas „professionelleres“ machen.

Ich würde mir Spring ansehen.

Danke für den Link.
Das braucht seine Zeit mich darin einzulesen!

 

[Tom299]

http://stackoverflow.com/questions/9017762/what-is-the-maximum-connections-for-sqlite3-database
http://stackoverflow.com/questions/3610775/how-many-connections-can-sqlite-3-handle

Wenn deine Klassen unabhängig voneinander sind, also ein insert oder update keine Auswirkung auf eine andere Klasse hat, dann würd ich die SQL-Statements in einer Liste sammeln und dann innerhalb einer Transaktion in die Datenbank übertragen. Nachteil ist aber z.B. wenn was schief geht und du machst ein Rollback, sind natürlich alle Daten aller Klassen für diese Transaktion zurückgesetzt.

 

[nvidia]

[...]
Ich frage ich aber was passiert, wenn die Methode "writeData" (schreibt die Daten in die DB) alle 500 fast zur selben Zeit aufrufen und Daten zum schreiben übergeben.[...]

Ich nehme an die writeData-Methode ist zustandslos, d.h. benötigt keine irgendwie gearteten Membervariablen ausser das zu schreibende Objekt. Dann passiert da nichts, da die Datenbank selbst Tabellen/Rows sperrt auf denen gerade geschrieben/gelesen wird. Ob das schön ist, ist eine andere Frage da man so nicht koordiniert mit dem "Backpressure" der Datenbank umgehen kann.