Strategie per Java Orm con rete inaffidabile e bassa larghezza di banda

Question

Sto cercando Hibernate un sistema che deve funzionare in una rete inaffidabile. Esiste un unico database centrale a cui abbiamo bisogno dell'accesso di lettura, ma è disponibile su una rete Wi-Fi piuttosto irregolare. Inoltre, potrebbero esserci perdite di potenza che non chiudono in modo pulito l'applicazione, quindi qualsiasi soluzione deve avere una cache persistente che può sopravvivere ai cicli di potenza. Infine, si tratta di un sistema incorporato con solo modesta memoria e spazio su disco, quindi ad esempio fare la replica completa del database non è una strategia fattibile.

Ho una comprensione di base della memorizzazione nella cache di 2 ° livello in letargo e mi chiedo se sia possibile configurarlo con qualcosa come ehcache per risolvere questo problema, ma la spinta principale di ciò sembra essere prestazioni non disponibilità, quindi non sono a conoscenza di Quali potrebbero essere le insidie.

Sono anche abbastanza disposto a considerare altre strategie che coinvolgono la replica in un database locale. Preferirei non dover fare troppo il sollevamento pesante per implementarlo.

Alla ricerca di un'esperienza o possibili alternative.

Answer 1

Il replicatore di Daffodil (http://enterprise.replicator.daffodilsw.com/index.html) consente la replica tra le fonti JDBC. Supporta aggiornamenti bidirezionali, fusione e risoluzione dei conflitti e repliche parziali.

Questo può essere utilizzato per sincronizzare il database principale con una replica locale (parziale). Puoi usare Hibernate per parlare con il database di replica locale e fare tutto il resto al di fuori di quel processo.

Answer 2

"Inoltre, potrebbero esserci perdite di potenza che non chiudono in modo pulito l'applicazione, quindi qualsiasi soluzione deve avere una cache persistente che può sopravvivere ai cicli di potenza."

Hai già una soluzione nella tua mente con cache di livello 2 in letargo. Ma non hai detto quali sono i requisiti reali. Hai una rete irrealizzabile. Va bene, hai un alimentatore irrealizzabile. Va bene anche questo. Ora che livello di servizio vuoi raggiungere? Cosa è accettabile o no?

La perdita di dati è accettabile? Quanto potresti accettare? Che rischio accetti?

Per essere più espliciti, supponiamo che tu abbia una replica locale del database o almeno una parte di esso. Lascia che tu sappia come mettere in coda/salvare la modifica fatta localmente. Supponiamo che memorizzi queste modifiche su un documento rigido per essere al sicuro in caso di insufficienza di corrente. Supponiamo che tu sia in grado di unire le modifiche al database principale quando la connessione è di nuovo disponibile.

Sono già molte ipotesi. Ok ma cosa succede se un harddrive fallisce dopo un powerfailure? Sai che HardDrive non piace l'insufficienza di potenza e tende ad essere corrotto sull'insufficienza di corrente o addirittura può essere danneggiato?

Quindi metti un raid e aggiungi un alimentatore ininterrotto. Bello. Il tuo evento di rilevamento dell'alimentazione dal sistema operativo. Termina la transazione attuale e l'arresto correttamente. RAID ti protegga da un fallimento del disco.

Ok, ma cosa succede se l'intero computer smette di funzionare? Cosa succede in caso di fuoco? O danni da acqua? Tutto il disco verrà gestito, i dati irrecuperabili e ciò che non è sincronizzato con il database centrale viene perso. È accettabile o no?

Anche quando il WiFi è acceso, l'alimentazione funziona perfettamente ... Qual è l'affidabilità del database centrale? Hai backup regolari? O una soluzione di clustering? Sei sicuro che il tuo database centrale sia affidabile comunque?

Dal punto di vista del database, è facile utilizzare un cluster o un backup e utilizzare le transazioni per garantire la dataconsistenzia. Puoi ancora perdere dati (se non si utilizza un cluster in particolare), ma dovresti essere in grado di recuperare fino all'ultimo backup per un esempio.

Ma se si desidera lavorare offline (con il database non disponibile) e non sei l'unico che può modificare il database, si verificheranno conflitti. Questo non è più una cache, un letargo o qualsiasi problema tecnico.

Questo è un problema funzionale. Cosa fare quando si verificano diverse modifiche offline e devi unire? Cosa è accettabile? Cosa non è. Questo potrebbe essere che su Reconnect, si applicano la modifica più recente, le modifiche più vecchie vengono scartate. Oppure vengono rilevati conflitti pteenziali e chiede all'utente di gestirli. Puoi provare ad applicare il cambiamento in coda e applicarli tutti ...

Tenderei a considerare che puoi offrire una "modalità offline" ma i tuoi utenti devono essere consapevoli di essere offline e dovrebbero avere una notifica quando la modifica viene resa permanente nel database centrale con eventuale risoluzione dei conflitti. Ma quello il mio punto di vista.

Answer 3

Non puoi aspettarti di avere successo con una rete come quella tra ibernazione e il database.

Ti consiglio di definire una serie di operazioni atomiche di alto livello e quindi di definire una serie di servizi (ad esempio) per loro. Oppure, se lo desideri, puoi usare SOAP e guardare le opzioni WS-* per i messaggi affidabili per prendersi cura dei tentativi e di tutti gli altri dettagli disordinati.

Oppure, potresti indagare se qualcosa come Cassandra attraverso il link funzionerebbe meglio di SQL o qualcos'altro grande nella replica.

Answer 4

Che ne dici di mettere in coda le operazioni DB su una coda di messaggi durevoli/persistenti e lasciare che un po 'di middleware di messaggistica gestisca il problema della rete?

A seconda di come lo fai, i problemi di coerenza (beh, "l'anomalia" è la parola giusta che immagino) possono sorgere, ma se hai una rete inaffidabile e desideri comunque prestazioni decenti, quindi accontentarti di coerenza rilassata potrebbe essere la strada da percorrere.

Sarei titubante a usare Ehcache ecc. Non sono stati progettati per questo e quindi potresti dover "allungare" il framework. Le code di messaggi invece hanno soluzioni progettate per tali scenari.

Answer 5

Se fosse solo un caso di connessione sporadica tra le due macchine, consiglierei di tenere un registro delle transazioni che può essere riprodotto e ogni voce contrassegnata come elaborata. La memoria limitata può renderlo difficile, però.

Forse puoi memorizzare il registro delle transazioni compresso, però.

Answer 6

Hibernate (e la cache del secondo livello) sono veramente Non progettato per questo. La mia ipotesi è che probabilmente saresti meglio usare un Java RDBMS incorporato su piccola scala (ad es. H2 o HSQLDB) come coda temporanea locale (nella modalità più durevole disponibile) e quindi sincronizzare con un thread di fondo. È quindi possibile fornire un'interfaccia utente di Sync Spinner collegata a quel thread di sfondo per fornire un certo grado di feedback per l'utente.

Per inciso, Hibernate è un po 'grasso da scaricare in un ambiente incorporato. Potresti invece considerare mybatis.