# Anwendungseinstellungen ohne Datei übertragen?



## Teetasse601 (9. Mai 2014)

*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 (9. Mai 2014)

> Kennt jemand eine Lösung ?


Einstellungen im RAM ändern


> in alle Instanzen


Verstehe ich nicht.


----------



## Teetasse601 (9. Mai 2014)

*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 (9. Mai 2014)

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 (10. Mai 2014)

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 (11. Mai 2014)

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 (11. Mai 2014)

> 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 (11. Mai 2014)

Teetasse601 hat gesagt.:


> 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 (11. Mai 2014)

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*


----------

