Qual è un buon schema per la sincronizzazione di database multiutente?

5

Sto lavorando su un sistema per consentire a più utenti di collaborare a un progetto online. Tutto è abbastanza semplice, tranne per mantenere gli utenti sincronizzati. Ogni utente ha la propria copia locale del database del progetto, che consente loro di apportare modifiche e testare le cose, e quindi di inviare gli aggiornamenti al server centrale. Ma questo si inserisce nella classica domanda di sincronizzazione: come fai a impedire a due utenti di modificare la stessa cosa e di calpestare il lavoro degli altri?

Ho un'idea che dovrebbe funzionare, ma mi chiedo se c'è un modo più semplice per farlo. Ecco il concetto di base:

  • Tutti i dati del progetto sono memorizzati in un database relazionale.
  • Ogni riga nel database ha un proprietario. Se l'utente corrente non è il proprietario, può leggere ma non scrivere quella riga. (Questo è il lato client forzato.)
    • L'utente può inviare una richiesta al server per assumere la proprietà di una riga, che sarà concessa se la copia del server dice che il proprietario corrente è NULL , o di rilasciare la proprietà quando hanno finito con esso.
    • Non è possibile rilasciare la proprietà senza apportare modifiche al server.
  • Non è possibile eseguire modifiche al server senza aver prima scaricato tutte le modifiche in sospeso sul server.
  • Quando vengono apportate modifiche alle righe che possiedi, un trigger contrassegna quella riga come sporca. Quando si commettono modifiche, il database viene scansionato per tutte le righe sporche in tutte le tabelle e i dati vengono serializzati in un file di aggiornamento, che viene pubblicato sul server e tutte le righe sono contrassegnate come Pulite. Il server applica gli aggiornamenti alla sua fine e mantiene il file in giro. Quando gli altri utenti scaricano le modifiche, il server invia loro i file di aggiornamento che non hanno ancora ricevuto.

Quindi, essenzialmente questa è una reinvenzione del controllo della versione su un database relazionale. (Sort of.) Finché assumere la proprietà e applicare gli aggiornamenti al server sono garantite modifiche atomiche e il server verifica che alcuni utenti smart-aleck non abbiano modificato il loro database locale in modo che possano inviare un aggiornamento per una riga che don ' Se ne detiene la proprietà, dovrebbe essere garantito che sia corretto e senza preoccuparsi di unire e unire conflitti. (Penso.)

Qualcuno può pensare a qualche problema con questo schema, o modi per farlo meglio? (E no, "costruisci [inserisci VCS qui] nel tuo progetto" non è quello che sto cercando. L'ho già pensato. I VCS funzionano bene con il testo, e non così bene con altri formati di file, come quelli relazionali banche dati).

    
posta Mason Wheeler 02.11.2012 - 00:24
fonte

1 risposta

2

Abbiamo creato un'applicazione molto simile diversi anni fa e usato praticamente lo stesso approccio.

L'unica cosa che è tornata a farci mordere è che abbiamo finito con un sacco di record assegnati a un utente che essenzialmente sono stati abbandonati. Gli utenti hanno richiesto la proprietà e quindi non hanno mai apportato alcuna modifica e non hanno mai rilasciato la proprietà. Ciò ha portato a record nel DB che non è stato possibile assegnare ad altri utenti.

Gli utenti non sempre fanno ciò che ci aspettiamo e in questo caso non prevedevamo che un utente avrebbe avviato un'unità di lavoro e quindi si sarebbe semplicemente fermato. Abbiamo dovuto implementare un processo per reimpostare la proprietà su null dopo che X era trascorso. Potrebbe non essere stata la soluzione migliore, ma è successo rientrare nei desideri del proprietario dell'attività commerciale.

    
risposta data 02.11.2012 - 13:33
fonte

Leggi altre domande sui tag