Server documenti:Gestione dei salvataggi simultanei

Question

Sto implementando un document server.Attualmente, se due utenti aprono lo stesso documento, quindi lo modificano e salvano le modifiche, lo stato del documento sarà indefinito (le modifiche del primo utente verranno salvate in modo permanente o del secondo).Ciò è del tutto insoddisfacente.Ho considerato due possibilità per risolvere questo problema:

Il primo è bloccare il documento quando viene aperto da qualcuno per la prima volta e sbloccarlo quando viene chiuso.Ma se la connessione di rete al server viene interrotta improvvisamente, il documento rimarrebbe in uno stato bloccato per sempre.La soluzione ovvia è inviare ping regolari al server.Se il server non riceve K ping consecutivi (K > 1) da un particolare client, i documenti bloccati da questo client vengono sbloccati.Se quel client riappare, i documenti vengono nuovamente bloccati, se qualcuno non li ha già bloccati.Ciò potrebbe essere utile anche se l'applicazione client (in esecuzione nel browser Web) viene terminata in modo imprevisto, rendendo impossibile inviare un segnale "esci, sblocca i miei documenti" al server.

Il secondo è archiviare più versioni dello stesso documento salvate da utenti diversi.Se le modifiche al documento vengono apportate in rapida successione, il sistema offrirà di unire le versioni o di selezionare una versione preferita.Per ottimizzare lo spazio di archiviazione, dovrebbero essere mantenute solo le differenze dei documenti (proprio come il software di controllo del codice sorgente).

Quale metodo dovrei scegliere, tenendo in considerazione che la connessione al server potrebbe A volte essere lento e insensibile?Come dovrebbero essere determinati i parametri (intervallo di ping, intervallo di successione rapida)?

PSSfortunatamente, non posso archiviare i documenti in un database.

Answer 1

Il mio suggerimento sarebbe qualcosa di simile al tuo primo.Quando il primo utente (Bob) apre il documento, acquisisce un blocco in modo che gli altri utenti possano solo leggere il documento corrente.Se l'utente salva il documento mentre lo sta utilizzando, mantiene il blocco.Solo quando esce dal documento, questo viene sbloccato e altre persone possono modificarlo.

Se il secondo utente (Kate) apre il documento mentre Bob ha il blocco su di esso, Kate riceverà un messaggio che dice che il documento non è modificabile ma potrà leggerlo finché il blocco non verrà rilasciato.

Quindi cosa succede quando Bob acquisisce il blocco, magari salva il documento una o due volte ma poi esce dall'applicazione lasciando il blocco in sospeso?

Come hai detto tu stesso, richiedere al client con il blocco di inviare ping a una determinata frequenza è probabilmente l'opzione migliore.Se non ricevi un ping dal client per un determinato periodo di tempo, significa effettivamente che il suo client non risponde più.Se si tratta di un'applicazione Web è possibile utilizzare Javascript per i ping.L'ultimo documento salvato rilascia il suo blocco e Kate può ora acquisirlo.

Un ping può contenere il nome del documento su cui il client ha un blocco e il server può calcolare quando è stato ricevuto l'ultimo ping per quel documento.

Answer 2

La prima opzione che descrivi è essenzialmente un modello di blocco pessimistico mentre la seconda è un modello ottimistico.Quale scegliere dipende in realtà da una serie di fattori, ma essenzialmente si riduce a come l’azienda vuole lavorare.Ad esempio, creerebbe indebiti disagi agli utenti se un documento che devono modificare fosse bloccato da un altro utente?Cosa succede se un documento viene bloccato e qualcuno va in vacanza con il proprio cliente connesso?Qual è la probabile contesa per ciascun documento, ad es.quanto è probabile che lo stesso documento venga modificato da due utenti contemporaneamente?, quanto sono localizzate le modifiche all'interno di un singolo documento?(Se la stessa sezione viene modificata regolarmente, l'esecuzione di un'unione potrebbe richiedere più tempo rispetto alla semplice modifica delle modifiche).

Supponendo che il conflitto sia relativamente basso e/o che la dimensione di ciascuna modifica sia piuttosto piccola, probabilmente opterei per un modello ottimistico che risolva i conflitti utilizzando un'unione automatica o manuale.È possibile utilizzare un numero di versione o un checksum del contenuto del documento per determinare se è necessaria un'unione.

Answer 3

Attualmente i documenti vengono pubblicati da un gruppo limitato di persone, ognuna delle quali lavora su un argomento separato.Pertanto, l'inconveniente introdotto dalle serrature è ridotto al minimo.Le persone per lo più estendono i documenti esistenti e correggono gli errori in essi contenuti.

Parlando del modello pessimistico, lo scenario del "client rimasto connesso per N giorni" potrebbe essere evitato impostando la data di scadenza del blocco, ad esempio, un giorno prima della data di inizio del blocco.Poiché i documenti modificati non sono affatto cruciali e vengono modificati da più utenti molto raramente, ciò potrebbe essere sufficiente.

Consideriamo ora il modello ottimistico.Come dovrebbero essere rilevate le differenze, se i documenti hanno una struttura regolare (ad esempio, gerarchica)?Altrimenti?Quali sono le possibilità di successo dell'unione automatica in questi casi?

La situazione diventa più complicata, perché alcuni documenti (modificati dal gruppo utenti 'admins') contengono importanti informazioni di configurazione (indice globale del documento, ruoli utente, ecc.).A mio avviso, i lucchetti sono più vantaggiosi proprio per questo tipo di informazioni, perché non cambiano quotidianamente.Quindi una soluzione ibrida potrebbe essere accettabile.

Cosa ne pensi?