Document Server: Manipularea conturilor salvate simultan

Am implementat un server de documente. În prezent, dacă doi utilizatori deschid același document, modificați-l și salvați modificările, starea documentului va fi nedefinită (fie modificările primului utilizator sunt salvate definitiv, fie cele de-a doua). Acest lucru este în întregime nesatisfăcător. Am analizat două posibilități pentru a rezolva această problemă:

The first is to lock the document when it is opened by someone the first time, and unlock it when it is closed. But if the network connection to the server is suddenly interrupted, the document would stay in a forever-locked state. The obvious solution is to send regular pings to the server. If the server doesn't receive K pings in a row (K > 1) from a particular client, documents locked by this client are unlocked. If that client re-appears, documents are locked again, if someone hadn't already locked them. This could also help if the client application (running in web browser) is terminated unexpectedly, making it impossible to send a 'quitting, unlock my documents' signal to the server.

Al doilea este de a stoca mai multe versiuni ale aceluiași document salvate de diferiți utilizatori. Dacă modificările aduse documentului sunt efectuate în succesiune rapidă, sistemul ar oferi fie pentru a îmbina versiunile, fie pentru a selecta o versiune preferată. Pentru a optimiza spațiul de stocare, ar trebui să se păstreze doar diferențele de documente (la fel ca software-ul de control al sursei).

Ce metodă trebuie să aleg, ținând cont de faptul că conexiunea la server ar putea fi lentă și nu răspunde? Cum ar trebui să se determine parametrii (interval ping, interval de succesiune rapidă)?

P.S. Din păcate, nu pot stoca documentele într-o bază de date.

0
fr hi bn

3 răspunsuri

Sugestia mea ar fi ceva de genul tău primul. Când primul utilizator (Bob) deschide documentul, el dobândește o blocare, astfel încât alți utilizatori să poată citi doar documentul curent. Dacă utilizatorul salvează documentul în timp ce îl folosește, el ține blocarea. Numai atunci când iese din document, este deblocat și alte persoane îl pot edita.

Dacă al doilea utilizator (Kate) deschide documentul în timp ce Bob are încuietoarea, Kate va primi un mesaj prin care se spune că documentul nu poate fi editat, dar poate să o citească până când blocarea a fost eliberată.

Deci, ce se întâmplă când Bob doboară blocarea, poate salvează documentul o dată sau de două ori, dar apoi iese din aplicație lăsând blocarea agățată?

Așa cum ați spus, solicitarea clientului cu blocarea pentru a trimite ping-uri la o anumită frecvență este probabil cea mai bună opțiune. Dacă nu primiți un ping de la client pentru o anumită perioadă de timp, acest lucru înseamnă că clientul său nu mai răspunde. Dacă aceasta este o aplicație web, puteți folosi JavaScript pentru ping-uri. Documentul care a fost salvat ultima dată eliberează blocarea și Kate o poate acumula.

Un ping poate conține numele documentului pe care clientul are blocat, iar serverul poate calcula momentul în care a fost recepționat ultimul ping pentru acel document.

0
adăugat

În prezent, documentele sunt publicate de un grup limitat de persoane, fiecare dintre ele lucrând pe un subiect separat. Deci, inconvenientele introduse de încuietori sunt minimizate. Oamenii extind cea mai mare parte documentele existente și corectează greșelile în ele.

Vorbind despre modelul pesimist, scenariul "client stâng conectat pentru N zile" ar putea fi evitat prin setarea datei de expirare a blocării, de exemplu, cu o zi înainte de data începerii blocării. Deoarece documentele editate nu sunt deloc critice și sunt modificate de mai mulți utilizatori destul de rar, ar putea fi de ajuns.

Acum, ia în considerare modelul optimist. Cum ar trebui detectate diferențele, dacă documentele au o structură obișnuită (adică, ierarhică)? Dacă nu? Care sunt șansele unei fuziuni automate reușite în aceste cazuri?

Situația devine mai complicată, deoarece unele documente (editate de grupul de utilizatori "administratori") conțin informații importante de configurare (indice global al documentului, roluri de utilizator etc.). În opinia mea, încuietorile sunt mai avantajoase pentru tocmai acest tip de informații, pentru că nu se schimbă în fiecare zi. Deci, o soluție hibrid ar putea fi acceptabilă.

Tu ce crezi?

0
adăugat

Prima opțiune pe care o descrii este în esență un model pesimist de blocare, în timp ce al doilea este un model optimist. Care dintre ele alege într-adevăr se reduce la un număr de factori, dar, în esență, se reduce la modul în care afacerea vrea să lucreze. De exemplu, s-ar provoca neplăceri utilizatorilor dacă un document pe care trebuie să îl editeze a fost blocat de un alt utilizator? Ce se întâmplă dacă un document este blocat și cineva merge în vacanță cu clientul său conectat? Care este concluzia probabilă pentru fiecare document - adică, cât de probabil este ca același document să fie modificat de doi utilizatori în același timp ?, cât de localizați sunt modificările care ar putea fi într-un singur document? (Dacă aceeași secțiune este modificată în mod regulat, efectuarea unei fuzionări poate dura mai mult decât simpla efectuare a modificărilor).

Presupunând că afirmația este relativ scăzută și/sau dimensiunea fiecărei schimbări este destul de mică, atunci probabil aș opta pentru un model optimist care rezolvă conflictele folosind o fuziune automată sau manuală. Un număr de versiune sau o sumă de control a conținutului documentului poate fi utilizat pentru a determina dacă este necesară o îmbinare.

0
adăugat