serializzazione degli oggetti mutanti

Question

serializzazione degli oggetti mutanti

Naviga le tue risposte

#1 da (2 voti)
#2 da (2 voti)
#3 da (2 voti)
#4 da (0 voti)

5

Nel nostro sistema un file multimediale può avere diversi stati:

non valida
vuoto
caricando
l'ingestione
pronto ...

.. a seconda dello stato, le informazioni sul supporto sono accessibili in diversi modi. Ad esempio:

Durante il caricamento, il nome del file si trova su un file JSON di informazioni temporanee sul file system.
Quando l'oggetto è pronto, il nome del file potrebbe essere indovinato guardando in un punto specifico del file system (ovvero sotto una directory chiamata dopo l'ID del supporto).

Lo stesso vale per l'attributo "progresso" di un media:

Durante il caricamento "progresso" rappresenta la dimensione del file / dei byte scaricati.
Durante la fase di importazione, il progresso rappresenta il numero del passo corrente / i passaggi del numero totale (thumbnailing, post-processing, ecc.)

Lo stato serializzato di un supporto viene utilizzato dall'interfaccia utente per riportare le informazioni all'utente.

Un MediumStateFactory prova un gruppo di% classi derivate da% co_de ( AbstractMediumState , MediumStateReady , ecc.) finché non si qualifica per gestire lo stato corrente del supporto.

Si scopre che per i file piccoli lo stato può cambiare durante la serializzazione: un MediumStateUploading può essere costruito all'inizio della serializzazione, ma quando lo stato dei media cambia, nel momento in cui viene eseguita la serializzazione effettiva non lo fa t rappresentano più i media, causando errori. Ad esempio, un MediumStateUploading si aspetta di recuperare la dimensione del supporto dal JSON temporaneo.

Al momento stiamo riavviando la serializzazione interamente se rileviamo un'eccezione durante il processo. Questa è una forza piuttosto bruta e abbastanza brutta.

Quale sarebbe il modo migliore per serializzare oggetti che possono mutare durante il processo di serializzazione?

object-oriented concurrency serialization

posta Charles 16.05.2016 - 13:33

fonte

4 risposte

Leggi altre domande sui tag object-oriented concurrency serialization

Ereditarietà dai bambini ai genitori? Utilizzo della memoria del tipo di stringa JavaScript con valori identici

score 2 · Answer 1

Mi rendo conto che la tua domanda riguarda specificamente la serializzazione, ma penso che potresti provare a risolvere il problema sbagliato qui. Ti suggerisco di pensare se hai preoccupazioni separate correttamente nella progettazione della tua applicazione. Potrebbe avere più senso considerare lo stato serializzato di un file multimediale come una composizione di alcuni ID univoci e alcune informazioni sullo stato eventualmente obsolete, e utilizzare quest'ultimo solo per le informazioni dell'utente. È quindi possibile delegare la contabilità reale basata su ID univoci a un'entità che non deve fare affidamento sulle informazioni sullo stato potenzialmente obsolete provenienti dall'interfaccia utente.

score 2 · Answer 2

Questo è il problema con gli oggetti mutabili, che possono mutare.

Ovviamente, se sei riuscito a serializzare correttamente lo stato che il tuo oggetto ha adesso, non sarà lo stato in cui il tuo oggetto avrà due secondi da adesso. Quindi avere lo stato serializzato non corrisponde allo stato corrente deve essere accettabile, altrimenti hai perso.

Se le modifiche al tuo oggetto sono indipendenti, ed è accettabile serializzare il tuo oggetto con qualsiasi serie di modifiche complete (ad esempio il set di file rimane invariato, ma lo stato di ogni file potrebbe cambiare), allora il più semplice sarebbe avere un blocco per ogni descrizione del file, e si guarda una descrizione del file attorno alla sua serializzazione, e attorno alle modifiche.

Se si dispone del threading appropriato, è possibile inviare la serializzazione e le modifiche dell'oggetto allo stesso thread seriale, il che renderebbe il blocco non necessario.

score 2 · Answer 3

Separa scritture e letture. Di seguito è riportato un modo per consentire che entrambi si verifichino contemporaneamente allo stesso file.

Forse hai bisogno di scrivere o cambiare lo stato dei media. Ha una lista di scrittori e un elenco parallelo di stati. Se la scrittura fallisce perché viola un'invocazione, cambia lo stato. Informerebbe l'elenco degli osservatori con lo stato.

La fabbrica di stato medio è un osberver. Ha una cache dello stato più recente. Esiste una schiera parallela di fabbriche di stato e astratte. Se lo stato più recente non lo modifica, ignora il metodo originale. Altrimenti, trova l'indice negli array e usa quella fabbrica astratta.

score 0 · Answer 4

È possibile e fattibile dividere i dati serializzati in parti? Una parte contenente la parte stabile dello stato e una piccola parte contenente la parte variabile dello stato.

In questo modo hai diverse opzioni:

puoi serializzare la parte del piccolo cambiamento ultima;
puoi utilizzare eventi, pattern di osservatori o paradigmi reattivi per serializzare la parte mutevole dello stato quando si verifica un cambiamento;
se la serializzazione è per la persistenza, potresti essere in grado di omettere la parte che cambia o di aggiungerla a un log di transazione sequenziale; o,
puoi riavviare la serializzazione solo della parte che cambia, proprio come fai ora.