Thread getriebene SQLite Zwischenschicht?!

[Mavarik]

Hallo Zusammen!

Ich habe folgende Situation:

Eine Software die in verschiedenen Filialen eingesetzt wird.
Zur Zeit hat jede Filiale einen eigenen MySQL-Server und es gibt einen globalen MySQL-Server im Internet.
Direkt auf dem globalen Server zu arbeiten ist zu langsam, da teilweise die Internetverbindung zu schlecht, langsam und instabil ist.

Es gibt zwei "FEDERATED" Tabellen. Eine für die Log's die andere für die Datenbank-Versionsverwaltung.

Wenn eine Datenbank geöffnet wird, schaut die Software erst nach, ob auf dem Server Datensatzänderungen sind, die erst auf den lokalen Server übertragen werden müssen. Nach dem Close schreibt die Software die geänderten Datensätze auf den globalen Server und gibt die Datenbank wieder frei.

Soweit so "gut"... Das funktioniert so recht gut seit ca. 3 Jahren.

Leider:
a.) passiert es immer wieder, dass während dem Datentransfer die Verbindung zum Server abraucht.
b.) ist ggf. die Wartezeit nach einem Open der Datenbank recht lange, wenn die andere Seite viele Daten eingefügt hat.

Daher überlege ich eine Zwischenschicht auf beiden Seiten ein zu führen. Diese soll als eigenständige Software oder als Thread im Hintergrund für den Abgleich sorgen.

Als Idee hatte ich eine Firedac Memtable gedacht, diese soll sowohl als Cache als auch als Puffer für die Übertragung dienen.

Oder hat jemand eine bessere Idee. (Bitte nur, wenn ich nicht das komplette Konzept umstellen muss) :stupid:

Grüsse Mavarik

[Jumpy]

Ich hab jetzt keine Ahnung von MySQL, aber kann man das die Datenbank(server) nicht selber (mit entsprechenden Tools) erledigen lassen? Stichworte vllt. Replikation oder Spiegelung von Datanbanken?

[rapante]

Was spricht denn gegen eine Master/Slave-Replikation?
Wir haben das bei uns zumindest so implemntiert, dass jede Filiale einen eigenen Slave-Server für Lesezugriffe hat
und geschrieben wird auf dem entfernten Master.

[p80286]

Schau mal hier rein, ich denke, daß sollte Dir weiter helfen.

Gruß
K-H

[Mavarik]

Das hat sich eigentlich von Anfang an ausgeschlossen, da SlaveA nicht die Datenbank auf SlaveB sperren kann.

Daher funktioniert das nicht..

Mavarik

PS.: Die Frage lautet... Firemonkey MemTable oder "nimm besser einen balSchnickschnackProviderComanndqueryproducer" <- keinen Plan...

Dachte sowas mit ApplyUpdates (noch nie versucht Schnickschnack...)

[Sir Rufo]

Das mit dem Thread verstehe ich nicht. Was ich verstehen würde wäre eine Service-Anwendung, die für den Abgleich sorgt. Allerdings sehe ich die nicht auf der Seite vom Hauptserver, der braucht die nicht.

Der Service kümmert sich fortlaufend um den Abgleich mit dem Hauptserver. Dazu sperrt er die Datenbank (so wie die Anwendung z.B. Status 1), trägt die Daten vom Hauptserver ein und gibt die Datenbank wieder frei (Status 0).

Während die Anwendung läuft erfolgt kein Abgleich. Wird die Anwendung beendet, dann wird die nicht freigegeben, sondern in den Status 2 (neue lokale Daten vorhanden) und ist damit für die Anwendung weiterhin gesperrt.

Jetzt verbindet sich der Service wieder mit der Datenbank, setzt den Status auf 1, überträgt die Daten zum Hauptserver und macht ansonsten den normalen Abgleich vom Hauptserver.

[Dejan Vu]

Die Idee von Sir Rufo würde bedeuten, irgendwie irgendwo ein zweites Programm zu starten. Fände ich auch naheliegend, wobei dann eventuell noch kleinere Synchronisationsprobleme gelöst werden müssen (Datensatz wird aktualisiert, während er in Bearbeitung ist).

Die Idee mit dem Thread ist dann verständlich, wenn kein zweites Programm laufen soll. Dann ist dieser 'Service' eben ein Thread.

[Sir Rufo]

Zitat:

Zitat von Dejan Vu (Beitrag 1278691)

Die Idee von Sir Rufo würde bedeuten, irgendwie irgendwo ein zweites Programm zu starten. Fände ich auch naheliegend, wobei dann eventuell noch kleinere Synchronisationsprobleme gelöst werden müssen (Datensatz wird aktualisiert, während er in Bearbeitung ist).

Die Idee mit dem Thread ist dann verständlich, wenn kein zweites Programm laufen soll. Dann ist dieser 'Service' eben ein Thread.

Das Sync-Problem ist doch schon gelöst (so wie es jetzt auch schon ist):

AKTUELL:

• Anwendung startet
  • Warten auf freie Datenbank (0)
  • Datenbank sperren (1)
  • Daten vom Hauptserver
• Anwendung endet
  • Daten zum Hauptserver
  • Datenbank freigeben (0)

VORSCHLAG:

• Anwendung startet
  • Warten auf freie Datenbank (0)
  • Datenbank sperren (1)
• Anwendung endet
  • Datenbank freigeben (2)
• Service Abgleich
  • Warten auf freie Datenbank (2)
  • Datenbank sperren (1)
  • Daten zum Hauptserver
  • Daten vom Hauptserver
  • Datenbank freigeben (0)
• Service Abgleich
  • Warten auf freie Datenbank (0)
  • Datenbank sperren (1)
  • Daten vom Hauptserver
  • Datenbank freigeben (0)

Alles was es da an Sync-Problemen aktuell gibt, werden mit diesem Ansatz nicht gelöst, ist aber auch nicht Gegenstand der Frage gewesen ;)

[p80286]

Was ich nicht verstehe "Datenbank sperren" ist doch ein unnötiger Flaschenhals Datensatz/sätze wäre mir einleuchtender.

Gruß
K-H

[Dejan Vu]

Genau, denn damit wird die lange Wartezeit bei vielen Änderungen nicht vermieden. Und wenn man den Datensatz sperrt, dann so kurz wie möglich und dann gibt es wieder 'race conditions', die gelöst werden müssen. Aber das ist ja alles keine Hexerei. Wenn z.B. ein Datensatz gerade zum Ändern gesperrt ist, kann er nicht aktualisiert werden. Dann würde eine Aktualisierung u.U. einen Reconcilekonflikt auflösen (Feld A wurde lokal und global verändert, wer gewinnt?)