Strategien für Java Orm mit unzuverlässigem Netzwerk und niedriger Bandbreite

Question

Ich möchte Hibernate nach einem System, das in einem unzuverlässigen Netzwerk arbeiten muss, angesehen. Es gibt eine einzige zentrale Datenbank, auf die wir Leseschreiber zugreifen müssen, aber sie ist über ein ziemlich fleckiges Wi-Fi-Netzwerk verfügbar. Darüber hinaus kann es Stromverluste geben, die die Anwendung nicht sauber herunterfahren, sodass jede Lösung einen anhaltenden Cache haben muss, der Stromzyklen überleben kann. Zuletzt ist dies ein eingebettetes System mit nur bescheidenem Speicher und Speicherplatz, sodass beispielsweise die vollständige Replikation der Datenbank keine praktikable Strategie ist.

Ich habe ein grundlegendes Verständnis für das Caching von Hibernate 2. Level, und ich frage mich, ob es möglich ist, dies mit so etwas wie EHCache zu konfigurieren, um dieses Problem zu lösen Was die Fallstricke sein könnten.

Ich bin auch bereit, andere Strategien zu berücksichtigen, die die Replikation in eine lokale Datenbank beinhalten. Ich müsste lieber nicht zu viel von dem schweren Heben selbst tun, um dies umzusetzen.

Auf der Suche nach Erfahrungen oder möglichen Alternativen.

Answer 1

Der Daffodil Replicator (http://enterprise.replicator.daffodilsw.com/index.html) ermöglicht die Replikation zwischen JDBC -Quellen. Es unterstützt bidirektionale Aktualisierungen, Zusammenführungen und Konfliktlösung sowie teilweise Repliken.

Dies kann verwendet werden, um die Hauptdatenbank mit einer lokalen (partiellen) Replikate zu synchronisieren. Sie können Hibernate verwenden, um mit der lokalen Replikatendatenbank zu sprechen und alles andere außerhalb dieses Prozesses zu erledigen.

Answer 2

"Darüber hinaus kann es Stromverluste geben, die die Anwendung nicht sauber herunterfahren, sodass jede Lösung einen anhaltenden Cache haben muss, der Stromzyklen überleben kann."

Sie haben bereits eine Lösung in Ihrem Kopf mit Hibernate Level 2 -Cache. Aber Sie haben nicht gesagt, was die wirklichen Anforderungen sind. Sie haben ein unwirkliches Netzwerk. Das ist in Ordnung, Sie haben unwirklichen Stromversorgung. Das ist auch in Ordnung. Welche Serviceebene möchten Sie nun erreichen? Was ist akzeptabel oder nicht?

Ist Datenverlust akzeptabel? Wie viel könnten Sie akzeptieren? Welches Risiko akzeptieren Sie?

Um expliziter zu sein, sagen Sie, Sie haben eine lokale Nachbildung der Datenbank oder zumindest einen Teil davon. Nehmen Sie an, Sie wissen, wie Sie vor Ort vorgenommen werden/speichern. Nehmen wir an, Sie speichern diese Modifikation auf einem Festplatten, um im Falle eines Stromausfalls sicher zu sein. Nehmen wir an, Sie können Änderungen mit der Hauptdatenbank zusammenführen, wenn die Verbindung wieder günstig ist.

Das sind schon viele Annahmen. Ok, aber was passiert, wenn ein hartnäckiger Fehler nach einer PowerFailure scheitert? Sie wissen, dass Harddrive keinen Stromausfall mag und dazu neigt, beim Stromausfall beschädigt zu werden oder sogar beschädigt werden kann?

Sie legen also einen Überfall und fügen eine ununterbrochene Stromversorgung hinzu. Das ist schön. Ihr Ereignis für Stromausfälle aus dem Betriebssystem. Beenden Sie Ihre aktuelle Transaktion und korrekt. Sie schützen Sie vor einem Scheibenversagen.

OK, aber was passiert, wenn der gesamte Computer nicht mehr funktioniert? Was passiert bei Feuer? Oder Wasserschäden? Alle Festplatten werden verwaltet, Daten nicht wiederherstellbar und was nicht mit der zentralen Datenbank synchronisiert wird, geht verloren. Ist es akzeptabel oder nicht?

Auch wenn das WLAN eingeschaltet ist, funktioniert die Stromversorgung perfekt ... Was ist die Zuverlässigkeit der zentralen Datenbank überhaupt? Hast du regelmäßige Backups? Oder eine Cluster -Lösung? Sind Sie sicher, dass Ihre zentrale Datenbank sowieso zuverlässig ist?

Aus Sicht der Datenbank ist es einfach, einen Cluster oder eine Sicherung zu verwenden und Transaktionen zu verwenden, um die Rechenzartzahl zu gewährleisten. Sie können weiterhin Daten verlieren (wenn Sie einen Cluster nicht speziell verwenden), sollten Sie jedoch in der Lage sein, sich bis zur letzten Sicherung für Exemples wiederzueregen.

Wenn Sie jedoch offline arbeiten möchten (mit nicht verfügbarer Datenbank), sind Sie nicht der einzige, der die Datenbank ändern kann, Konflikte treten auf. Dies ist kein Cache, kein Hibernate oder etwas technisches Problem.

Dies ist ein funktionales Problem. Was tun, wenn mehrere Modifikationen offline auftreten und Sie zusammenführen müssen? Was ist akzeptabel? Was ist nicht. Dies könnte sein, dass bei der Wiederverbindung die jüngste Änderung ältere Änderungen verworfen werden. Oder ptentiale Konflikte werden erkannt und fordert den Benutzer auf, sich mit ihnen zu befassen. Sie können versuchen, Änderungen in der Warteschlange anzuwenden und alle anzuwenden ...

Ich würde in der Lage sein, dass Sie einen "Offline -Modus" anbieten können, aber Ihre Benutzer müssen sich bewusst sein, dass sie offline sind, und sollten eine Benachrichtigung haben, wenn die Änderung in der zentralen Datenbank mit späterer Konfliktlösung dauerhaft gemacht wird. Aber das mein Standpunkt.

Answer 3

Sie können nicht erwarten, mit einem Netzwerk wie dem zwischen Hibernate und der Datenbank erfolgreich zu sein.

Ich empfehle Ihnen, eine Reihe von atomaren Operationen auf hoher Ebene zu definieren und dann eine Reihe von (z. B.) erholsamen Diensten für sie zu definieren. Oder, wenn Sie möchten, können Sie Seife verwenden und die WS-* -Optionen für zuverlässige Nachrichten ansehen, um sich um Wiederholungen und alle anderen unordentlichen Details zu kümmern.

Oder Sie könnten untersuchen, ob so etwas wie Cassandra auf dem Link besser funktionieren würde als SQL oder etwas anderes, das die Replikation groß ist.

Answer 4

Wie wäre es mit der Warteschlange für DB -Operationen in einer dauerhaften/persistenten Meldungswarteschlange und lassen Sie einige Messaging Middleware das Netzwerkproblem verarbeiten?

Je nachdem, wie Sie es tun, können Konsistenzprobleme (na ja, "Anomalie" ist das richtige Wort, das ich denke) auftreten kann, aber wenn Sie ein unzuverlässiges Netzwerk haben und dennoch eine angemessene Leistung wünschen, kann es der richtige Weg sein, sich für entspannte Konsistenz zu entspannen.

Ich würde zögern, EHCACHE usw. zu verwenden. Sie waren nicht dafür ausgelegt, und daher müssen Sie möglicherweise das Framework "strecken". Message -Warteschlangen hingegen haben Lösungen, die für solche Szenarien entwickelt wurden.

Answer 5

Wenn es sich nur um eine sporadische Verbindung zwischen den beiden Maschinen handelte, würde ich empfehlen, ein Transaktionsprotokoll zu behalten, das zurückgespielt und jeder Eintrag als verarbeitet markiert werden kann. Das begrenzte Gedächtnis kann dies jedoch schwierig machen.

Vielleicht können Sie das Transaktionsprotokoll komprimiert.

Answer 6

Winterschlaf (und der Cache der zweiten Ebene) sind Ja wirklich nicht dafür ausgelegt. Ich vermute, dass Sie wahrscheinlich am besten mit einem eingebetteten Java-RDBMS (z. B. H2 oder HSQLDB) als lokale temporäre Warteschlange (im haltbarsten verfügbaren Modus) mit einem Hintergrund-Thread eingebettet sind. Sie können dann eine Sync -Spinner -Benutzeroberfläche bereitstellen, die an diesen Hintergrund -Thread angeschlossen ist, um dem Benutzer ein gewisses Maß an Feedback zu geben.

Hibernate ist übrigens ein bisschen fett, um in eine eingebettete Umgebung zu werfen. Vielleicht möchten Sie stattdessen MyBatis in Betracht ziehen.