Synchronisation Datenquelle und Anwendung (Multi-User)

[AlArenal]

Folgende Situation:
Für eine neu zu erstellende Anwendung suche ich einen Weg den Datentopf (eine SQL-Datenbank) und die aus den Daten generierten Instanzen in einer Anwendung zu synchronisieren. D.h. Änderungen an den Instanzen führt zu INSERT/UPDATE/DELETE in der DB und die Anwendung muss nach INSERT/UPDATE/DELETE in der DB seine Datenstrukturen und Instanzen entsprechend abändern.
Die Daten selber werden nicht mit JDBC hin- und hergeschoben, sondern über einen Webservice (XML-RPC).

Ansatz:
1. Jede Tabelle der DB bekommt ein Feld mit einem Timestamp, der bei INSERT/UPDATE mit dem aktuellen Wert belegt wird.
2. Vor einem UPDATE wird geprüft, ob die vorhandene Zeile keinen neueren Timestamp hat / überhaupt noch vorhanden ist.
3. (Un-)Regelmäßig wird der aktuellste Timestamp der Tabellen gelesen und abgeglichen. Differenzen führen zur Synchronisierung der Instanzen.


Derzeit frage ich mich noch wie ich das Ganze in der Anwendung möglichst vorausschauend umsetze. Soll ich meine Daten-Objekt-Instanzen zentral observieren lassen, so dass Änderungen an ihnen zentral registriert und an die DB weitergereicht werden können? Speichere ich den Timestamp dann in den Instanzen, oder ebenfalls zentral in einer Map? Detektiere ich Änderungen an der DB mit nem Thread und nem Timer im Hintergrund, oder erst beim nächsten nötigen Zugriff auf die Datenbank?

Irgendwie finde ich im Netz nichts richtiges zum Thema, mglw. kommt bei den Suchbegriffen auch erst alles andere, aber nicht das, was ich speziell suche. Die Problematik als solche kann aber nicht neu sein, d.h. es muss irgendwo Erfahrungswerte geben..

 

[TRunKX]

Sieh dir mal CVS Systeme an die arbeiten da auch mit. Problem wird werden wen ein Datensatz gleichzeitig von 2 oder mehr Leuten geändert wird. Angezeigte Daten sind bei Multi USer nicht immer Aktuell da du jedem User ja eine Kopie aushändigen musst damit er damit arbeiten kann. Dann stellt sich die Frage ist die letzte Modifikation immer die beste? Oder kann es sein das die Modifikationen die der Cheff macht immer die besten?

Naja alles fragen die geklärt werden müssen bevor du da näher reingehst. Achja ich glaube ich habe mich jetzt dazu hinreissen lassen virl zu viel und am Thema vorbei zu schreiben.


Also meine Empfehlung jeder bekommt beim Start ne aktuelle DB und darf dann arbeiten alle Stunde wird abgeglichen und es wird alles was geändert wurde implementiert bei doppeländerungen bekommt immer der letzte den Zuschlag!

 

[Sky]

wen ein Datensatz gleichzeitig von 2 oder mehr Leuten geändert wird.

"gleichzeitig" kann man einen Datensatz nicht ändern. An irgendeiner Stelle wird wohl in eine Sequenz gebracht werden.

Angezeigte Daten sind bei Multi USer nicht immer Aktuell da du jedem User ja eine Kopie aushändigen musst damit er damit arbeiten kann. Dann stellt sich die Frage ist die letzte Modifikation immer die beste? Oder kann es sein das die Modifikationen die der Cheff macht immer die besten?

Hier ist das einfachste: Wurde ein Datensatz zwischenzeitlich geändert, so werden Änderungen, die auf dem Datensatz basieren nicht akzeptiert.

Also meine Empfehlung jeder bekommt beim Start ne aktuelle DB und darf dann arbeiten alle Stunde wird abgeglichen und es wird alles was geändert wurde implementiert bei doppeländerungen bekommt immer der letzte den Zuschlag!

Das kommt m.E. ganz auf die Anforderung an. Je nachdem wer wie oft welche Daten ändert kann es von "Aktualisierung nur beim Versuch Datensatz zu ändern" bis "sofortige Aktualisierung bei Änderung in der DB" viele Möglichkeiten geben.

 

[TRunKX]

... *mowl* :bae:

Hast ja recht...... :!: Aber man schreibt nicht nur Artikel zum Kommentieren vorhergegangener Artikel.

:meld: Aber du hast das mit 2 oder mehr falsch verstanden es ging darum wann die Daten eintreffen die geändert wurden. Und wen ein DS geändert wurde aber bei jemandem anderen bearbeitet wird. Wenn dann der 2. nicht schreiben darf dann kann ich nicht vernünftig arbeiten! :meld:

 

[Sky]

Wenn dann der 2. nicht schreiben darf dann kann ich nicht vernünftig arbeiten! :meld:

Naja, aber das ist erstens doch wieder Abhängig von der Anforderung und zweitens das einfacher als dein Vorschlag mit der Entscheidungslogik ("stellt sich die Frage ist die letzte Modifikation immer die beste?").

 

[TRunKX]

:### Ich wühle mal Firmenunterlagen zu dem Mist jetzt bin ich leicht angepisst! :### :!: Und siehe da! Sollten 2 Änderungen gemacht worden sein so wird dem der die letzte Änderung macht beides Vorgelegt wie bei einem CVS und er muss entscheiden was bleibt!

ISt auf Jeden Fall mal nen guter Ansatz um das (vermutlich fast nie) auftretende Problem zu beheben!

 

[AlArenal]

Hier ist das einfachste: Wurde ein Datensatz zwischenzeitlich geändert, so werden Änderungen, die auf dem Datensatz basieren nicht akzeptiert.

Also SELECT vor UPDATE (und ggf. auch vor INSERT, wenn man noch Fremdschlüssel braucht) und ZUrückweisen der Änderung, wenn die DB nen aktuelleren Stand hat als die lokalen Daten. An sowas hatte ich auch gedacht.

Also meine Empfehlung jeder bekommt beim Start ne aktuelle DB und darf dann arbeiten alle Stunde wird abgeglichen und es wird alles was geändert wurde implementiert bei doppeländerungen bekommt immer der letzte den Zuschlag!

Ich kann nicht jedem eine Kopie der DB geben. Die DB besteht sowohl aus anwendungsspezifischen Tabellen, zu denen auch die anderer Anwendungen gehören, deren Datenbestände untereinander verlinkt sind und wo man nie weiß wer da gerade wie drauf Zugriff hat

Das kommt m.E. ganz auf die Anforderung an. Je nachdem wer wie oft welche Daten ändert kann es von "Aktualisierung nur beim Versuch Datensatz zu ändern" bis "sofortige Aktualisierung bei Änderung in der DB" viele Möglichkeiten geben.

Naja, sofortige Aktualisierung scheidet bei der Anbindung eines Java-Clients über einen Web-Service aus, da nur der Client Anfragen initiieren kann. Der Server ist gewissermaßen "dumm". Vermutlich werde ich mit "Aktualisierung nur beim Versuch Datensatz zu ändern" beginnen, anschließend eine manuelle Aktualisierung implementieren und später evtl. vielleicht. auch ne periodische.

 

[Bleiglanz]

gutmütig

mit timestamp, der erste gewinnt, der zweite kriegt ne Fehlermeldung

heisst irgendwie "optimistic offline concurrency"

paranoid:

globaler Lock auf den Record: nur immer einer darf den überhaupt auschecken, timeout erforderlich usw.


gar nichts zu tun, so dass der zweite gewinnt und der erste (unbemerkt) verliert macht man eigentlich NIE (eventuell halt bei supervolatilen sachen)


ganz brauchbar ist:

"Patterns of Enterprise Applications" von Fowler, der diskutiert einige Ansätze, sonst kenne ich auch nix gescheites