Anwendungseinstellungen ohne Datei übertragen?

[Teetasse601]

Hallo zusammen,

ich bin leider in Sachen Netzwerkprogrammierung nicht so bewandert
und wollte daher fragen, ob es eine Methode gibt, Anwendungseinstellungen
plattformunabhängig ohne Speichern in eine Datei in alle Instanzen meiner
Anwendung zu übertragen. Dateioperationen versuche ich zu vermeiden, da es
dort immer wieder zu Schreibsperrungen & co. kommt. Ich dachte mir,
es gibt bestimmt eine Klasse dafür, aber sicher bin ich mir da leider nicht.

Kennt jemand eine Lösung ?

Eure
Teetasse601

 

[turtle]

Kennt jemand eine Lösung ?

Einstellungen im RAM ändern

in alle Instanzen

Verstehe ich nicht.

 

[Teetasse601]

Hallo turtle,

meine Frage war, wie man, wenn man sein Programm mehrfach
geöffnet hat, und in einem der offenen Fenster etwas ändert,
die geänderten Einstellungen mit den anderen offenen Fenstern (den
anderen Prozessen der eigenen Anwendung) synchronisieren kann.
Und ob es einen Weg gibt, dies ohne das Speichern in einer Datei zu tun.

Es geht hier also um das Übermitteln von Einstellungen
von einem Prozess meiner Anwendung an alle anderen Prozesse
meiner Anwendung, nur weiß ich nicht, wie genau ich das
angehen sollte. Wahrscheinlich braucht man dafür ein
Protokoll wie TCIP/IP ( oder braucht man Sockets ? ) .

Hat jemand eine Idee ?

Teetasse601

 

[Androbin]

Du kannst dir doch einfach deine "Programm-Instanzen" in einer ArrayList speichern und diese dann darüber synchronisieren :bloed:
Funktioniert natürlich nur, wenn du diese von einem zentralen Ort aus instanziierst, da du sonst keine Referenzen mehr auf deine Programme hast, über die du operieren kannst :toll:

 

[turtle]

Ah, jetzt verstehe ich dein Problem

Und nein man braucht dafür keine Sockets...

Nehmen wir an, das deine Applikation auf einer Datenbank basiert. Dann können alle Applikations-Instanzen ja die geänderten Einstellungen aus der DB lesen und bemerken,das "jemand" diese geändert hat.

Nun würde ich nicht unbedingt zu einer DB raten, aber stattdessen zu java.util.Preferences raten.

Ich vermute deine nächste Frage wird sein, wie denn alle anderen Applikations-Instanzen "sofort" informiert werden, wenn Einstellungen geändert werden?

Dies ist in der Tat eine weitreichende Frage und ich kann wieder nur auf das DB-Modell zurückkommen.

Nehmen wir wieder an, deine Applikation ist der Server-Teil an dem mehrere hundert Clients angemeldet sind. Nun ändert ein Client Daten in der DB. Möchtest du wirklich an die anderen hunderte Clients die Information schicken, das da was passiert ist? Dies hat zumindest miserable Performance zur Folge. Daneben kann es ja durchaus passieren, das ein Client gerade Dinge tut, wo ein Update nicht geht. Und in der Tat benötigst du, wenn du meinst, das zu benötigen eine Art der Synchronisation von Server (Client der ändert) zu Clients (die auf Änderungen horchen).

Ich sehe nicht, warum beim Start die Einstellungen gelesen werden und wenn ein Client sie ändern möchte, feststellt, das jemand andere hier schon Änderungen vorgenommen hat und dann entscheidet den Benutzer zu informieren, ob er A überschreiben oder B abbrechen und mit den geänderten Daten weiter arbeiten möchte.

Solange der Client X arbeiten kann, verstehe ich nicht, warum er "sofort" informiert werden muss?

Wenn das doch der Fall sein muss, (Beispiel?), gibt es natürlich noch die Möglichkeit des Einsatzes eines WatchService. Damit kannst du überwachen, ob sich ein Directory/Datei geändert hat und deine Applikations-Instanz wird informiert. Dann wirst du wahrscheinlich auf eine "normale" Properties Datei zurückgreifen und diese überwachen wollen.

 

[fischefr]

Also beim Logging gibt es häufig die gleiche Problemstellung: Man möchte das Logging Level ändern ohne die Anwendung neu zu starten. Daher wird hier oft von der Anwendung in regelmäßigen Intervallen das Änderungsdatum der Konfigurationsdatei geprüft. Wenn eine Änderung festgestellt wird, wir das Logging neu initialisiert und die Konfigurationsdatei neu gelesen.
Das ist natürlich nur bei relativ wenigen Instanzen und relativ seltenen Änderungen praktikabel - aber sehr einfach umzusetzen.

 

[turtle]

Daher wird hier oft von der Anwendung in regelmäßigen Intervallen das Änderungsdatum der Konfigurationsdatei geprüft

Weil die meisten Logging-Frameworks aus einer Zeit kommen, wo es noch den WatchService, aka Java-7, gab.

 

[mjustin]

Es geht hier also um das Übermitteln von Einstellungen
von einem Prozess meiner Anwendung an alle anderen Prozesse
meiner Anwendung, nur weiß ich nicht, wie genau ich das
angehen sollte. Wahrscheinlich braucht man dafür ein
Protokoll wie TCIP/IP ( oder braucht man Sockets ? ) .

TCP/IP basiert auf Sockets

Gibt es einen Prozess, der als ein "Boss" allen anderen Prozessen
geänderte Einstellungen zufunken soll, ist neben Eigenkreationen
zum Beispiel das neue WebSockets Protokoll geeignet.

Die anderen Prozesse verbinden sich dabei mit dem "Boss"
und dieser kann dann per Socket Daten an einen oder alle anderen
Prozesse senden.

Es komplett selber zu erstellen ist sicher auch möglich, der Server
muss dazu einen Port öffnen, die Clients verbinden sich, und lesen
(blockierend) aus dem InputStream des Sockets. Dies natürlich ein
einem Thread.

 

[turtle]

Ich weiß nich, ob dem TO bekannt ist, welche Implikationen dieses alles nach sich zieht.

Beispielsweise musst du als Erstes ein Boss-Programm starten,damit sich alle Client-Applikationen bei ihm registrieren können. Daneben muss eine Bibliothek beim Boss und den Clients installiert sein, damit ein Push-Service gemacht werden kann. Weiterhin muss die Kommunikation multi-threaded programmiert sein. Schlussendlich ist nicht gewährleistet, das eine Änderung vom Boss überhaupt in dem was ein Client gerade macht überhaupt in den Client-Ablauf reinpasst.

Alles zusammengenommen tendiere ich dann doch dazu, eine Datenbank ins Spiel zu bringen. Diese Technik ist ausgereift, sofort einsetzbar und alles was gelernt wird kann man in weiteren Projekte nutzen. Gibt es mal DB-Probleme findet man sicher tausende von Ideen, was gemacht werden kann.

Eine Client-Applikation wird dann nicht informiert, sondern holt sich selbst die neusten Einstellungen von der DB. Datenbank ausgelegt auf viele Benutzer und multi-threaded.

Mein Argument ist immer noch gültig, das dies zu schlechter Performance führt, wenn zu oft die DB gefragt wird ob sich Einstellungen geändert haben. Abhilfe vielleicht Caching oder periodische Client-Jobs