Recentemente ho postato una domanda qui: Metodi per condividere la memoria o lo stato tra le JVM? e apprezzare le risposte. Tuttavia, mentre leggevo il codice e imparavo meglio il sistema, ho imparato che avevo complicato il problema. Solo una delle JVM si preoccupa davvero dei dati dinamici, quindi non è necessario passare dati dinamici attraverso i limiti della memoria. Tuttavia, abbiamo ancora un problema che stanno mantenendo manualmente lo stato tra in-memory e sql; il codice manuale non è perfetto e non protegge da dati obsoleti, dati razziali, ecc. ecc. e voglio rimuoverlo interamente in un modo o nell'altro, così posso sentirmi più sicuro riguardo alla stabilità eccessiva.
Poiché solo una JVM si preoccupa dei dati dinamici e i dati dinamici possono essere rigenerati all'avvio ogni volta (con una piccola penalità di tempo per farlo) la mia inclinazione è quella di rimuovere tutti i dati dinamici da sql e di archiviare tutto in memoria ; perché complicare ulteriormente qualcosa?
Comunque, hanno apprezzato sql come strumento di debug. Questo sistema è sviluppato agile, è su un sistema live ma i bug e gli errori si verificano a causa della natura agile. Quando ciò accade, eseguono ssh sul sistema live e eseguono il debuging al volo; spesso visualizzando il database. L'SQL consente loro di vedere i percorsi e il percorso effettivi che vengono utilizzati. Possono anche vedere quando una rotta sembra sbagliata, cambiarla, quindi riavviare il modulo in modo che il percorso fisso venga caricato in memoria e utilizzato da quel momento in poi. A loro piace questa capacità di correggere rapidamente i percorsi sbagliati e non vogliono perderli.
Si parla ora di mantenere il database ma di farlo da hybernate per evitare l'incubo di cercare di mantenere manualmente JVM e sql sincronizzati. Ci sono alcuni altri guadagni minori, ma questo è principalmente in modo che possano mantenere lo sql e provare a usarlo come strumento di debug.
C'è qualcosa di sbagliato in tutto questo, ma non sono completamente sicuro di sapere cosa ci sia di sbagliato in questo. Se eliminassimo i dati dinamici di sql, potrei emulare parzialmente ciò che vogliono aggiungendo messaggi per stampare il grafico così com'è o per modificare un grafico al volo, ma ovviamente ogni messaggio richiede un po 'di tempo per scrivere. Mantenere il SQL piuttosto che provare a scrivere messaggi per consentire il cambio di memoria al volo ha senso?
Penso che l'uso dell'ibernazione possa rendere un po 'più difficile scrivere gli oggetti che usiamo per generare e mantenere i percorsi, dovendo mantenere lo structor simile a un database SQL e tutto. Ma penso che il mio vero problema sia l'idea di spingere i cambiamenti al nostro stato in memoria cambiando il nostro database. Mi sembra pericoloso; nello stesso modo in cui l'incapsulamento improprio è sbagliato. Non credo che mi piaccia l'idea di riparare un percorso interrotto semplicemente cambiando manualmente il percorso in sql. Ma non so come articolare il motivo per cui tutto ciò sembra sbagliato. Forse dovrei suggerire una soluzione di debug migliore?
Quindi, ho ragione di preoccuparmi o di essere in letargo davvero il miglior approcro?