Daten synchronisieren in Multi-Client-Anwendungen (Hibernate)

[javabar]

Hallo!

Ich entwickle gerade eine DB-Anwendung, bei der es mehrere Clients auf verschiedenen Rechnern geben soll, die alle auf die gleiche Datenbank zugreifen.

Man kann - was ja Standard ist - sowohl Daten ändern als auch in einer Übersicht anzeigen.

Wenn jemand einen Datensatz ändert, z.B. eine Aufgabe als erledigt markieren, sind die Informationen auf den anderen Clients nicht mehr aktuell...

Alle n Sekunden eine neue SQL-Abfrage an die Datenbank zu senden, wäre die einfachste, aber in Sachen Performance die uneleganteste Lösung.

Gibt es gute Praktiken oder fertige Lösungen, um Clients zu verständigen, wenn die Daten/Ansichten nicht mehr aktuell sind?

Viele Grüße

Egon Schmid

 

[Nightmares]

Du könntest serverseitig eine "Liste" anlegen, in derer du speicherst was gerade jemand mit seinem Client offen hat. Wenn Änderungen vorgenommen werden musst du dann dem Client eine Nachricht schicken. Das ganze setzt dann aber vorraus, dass die Clients sich nicht direkt mit der Datenbank verbinden sondern mit einer Java Anwendung auf dem Server und nur dieser hat dann eine Verbindung zur Datenbank. Alle Daten die von den Clients geschrieben oder gelesen werden gehen dann durch den Server.

 

[oopexpert]

Jede Konfliktdomäne sollte ein Versionsnummer bekommen. Das Polling schickt dann nur die Versionsnummern der Konfliktdomäne und den Zeitstempel des letzten Serverkontakts als Anfrage zum Server. Es werden dann vom Server nur Änderungsinformationen zum Client geschickt.

Direktes Informieren anderer Clients ist zwar möglich, kollidiert aber eventuell mit Isolationswünschen der Anwender, im schlimmsten Fall sogar mit parallel geänderten Daten der Konfliktdomäne. Andere Clients möchten wahrscheinlich ersteinmal ihre eigenen Änderungen machen und ggf. einen Merge vollziehen. Dies ist ein Randthema des Optimistisches Sperrverfahrens, wie man es z.B. von SVN oder CVS kennt.

Du kannst auch pessimistisch Sperren, sodass andere nur lesenden Zugriff haben zum Zeitpunkt der Änderung durch einen Client.

Das Pollen kann auch durch bidirektionales asynchrones Messaging realisiert werden. So oder so: Du kommst nicht um das Isolationsproblem herum.

 

[DerMitDenDaten]

Hallo

Ich habe ein ähnliches Problem wie javabar. Ich habe mehrere Clients die auf die gleiche Datenbank zugreifen. Es handelt sich um ein kleines Shopverwaltungssystem. Was passiert nun wenn diese Programme gleichzeitig eine Änderung in die DB schreiben wollen? Also z.b. wird von einem Client die Adresse von Kunde X geändert und vom anderen Client wird die Telefonnummer vom gleichen Kunden geändert. Dann ist doch nachher nur eine der Änderungen drinnen oder? Also entweder die neue Telefonnummer oder die neue Adresse. Sehe ich das richtig?
Das lässt sich wahrscheinlich so wie von Nightmares beschrieben lösen, indem alles erst über einen Server läuft der die Zugriffe verwaltet. Allerdings ist mir das ehrlich gesagt viel zu viel Aufwand und es fehlt mir wahrscheinlich auch die Erfahrung (programmiere erst seit 1 Jahr Java). Es wäre auch ok wenn immer nur einer im Shop auf einen Datensatz zugreifen kann und die anderen benachrichtigt werden das sie erst warten sollen bis der eine fertig ist. Da es nur 4 Clients gibt die auf nebeneinander stehenden PCs laufen von denen eh nie alle belegt sind wäre das vertretbar. Kann man das irgendwie lösen, ohne dass ich einen Server dazwischen schalten muss?

 

[oopexpert]

Die Zugriffe müssen grundsätzlich über einen Server verwaltet werden, denn nur er hat Meta-Wissen über potentielle Konfliktsituationen in Multi-User-Umgebungen.

Die Frage ist, reicht für die nicht-funktionalen Anforderungen eine 2-Schicht-Architektur oder muss es noch ein Applikationsserver sein. Auch mit einer 2-Schichtarchitektur ist es möglich solche Konfliktsituationen zu behandeln.

Es sind viele Möglichkeiten denkbar, welche auch teilweise vom DB-System abhängen (hier ORACLE). Hier nur einige:

1. Client mit DB-Server und Zugriffschicht mit PL/SQL.
2. Client mit DB-Server und explizitem Locking (select for update, lock table for exclusive mode)
3. Client mit DB-Server und implizitem Locking (Unique constraints)

 

[DerMitDenDaten]

Was ist wenn ich zum Kunden einen Timestamp speichere wann er zuletzt geändert wurde. Dann bevor ich ihn in der Datenbank editiere lese ich den Timestamp aus und vergleiche ihn mit dem Timestamp den ich vom letzten Auslesen der Kundendaten habe. Ist er gleich hat kein anderer Client etwas verändert und ich kann meine Daten schreiben. Ist er nicht gleich hat jemand etwas verändert und ich muss die aktuellen Daten erst mal auslesen, diese mit meinen Änderungen mergen und erst dann schreibe ich in die Datenbank. Dann muss der User zwar die Änderungen erneut machen, aber da ich davon ausgehe dass diese Situation ganz ganz selten auftritt (beim jetzigen system wurde immer unsynchronisiert auf die db zugegriffen und es gab nie probleme) wäre das verschmerzbar. Wenn ich die Schritte Timestamp lesen - Timestamp prüfen - Daten schreiben atomar mache (JDBC Transaction) müsste es doch auch ohne Server funktionieren, oder?

 

[oopexpert]

...müsste es doch auch ohne Server funktionieren, oder?

Ohne Server gehts nicht. Auch ein DB-Server ist ein Server.

Wenn ich die Schritte Timestamp lesen - Timestamp prüfen - Daten schreiben atomar mache (JDBC Transaction) müsste es doch auch ohne Server funktionieren, oder?

Vom Prinzip ja. "Timestamp lesen" müsste dabei ein select for update sein. Es ist sozusagen deine Eintrittskarte in die Konfliktdomäne. Andere Transaktionen werden dann daran gehindert, auch ein select for update durchzuführen. Für die anderen Transaktionen ist je nach Konfiguration "Warten" oder "Abbruch" angesagt. ("select for update", oder "select for update nowait")