Jak radzisz sobie z wieloma użytkownikami edytującymi ten sam fragment danych w aplikacji internetowej?

Pracuję nad projektem, który ma na celu stworzenie aplikacji internetowej, która będzie zarządzać listą zadań między wieloma użytkownikami. Jest to główna lista zadań, której elementy zadania są dystrybuowane przez autoryzowanego użytkownika. Każdy użytkownik ma swoje własne konto do logowania i przeglądania przypisanych mu zadań; możliwe jest, że wielu użytkowników ma jedno wspólne zadanie.

Staram się pomijać szczegóły projektu, ponieważ bardziej zmagam się z ogólną koncepcją radzenia sobie z następującymi sytuacjami, ale jeśli to pomaga, używam Java, EclipseLink i GWT z zaimplementowanym RequestFactory. Baza danych to PostgreSQL.

Tak więc problemy koncepcyjne, które próbuję pogodzić, są następujące:

1. Jeśli jedno zadanie wspólne dla wielu użytkowników zmieni się w jakikolwiek sposób, np. Zadanie ukończone, usunięte itp., Lista zadań wszystkich użytkowników, którzy mają to zadanie, zostanie zaktualizowana. Jakie wzorce projektowe pomagają w realizacji tej funkcji?

   • Niektóre wzorce, na które patrzyłem, to Obserwator i Pośrednik - czy są inne, które należy rozważyć?

2. Powiedzmy, że dwóch użytkowników zmienia to samo zadanie w tym samym czasie.

   • Po pierwsze, czy powinienem dopuścić do zaistnienia takiej sytuacji, czy powinienem ją zablokować, dopóki jedna lub druga osoba nie dokona zmian?

   • Po drugie, jeśli nie zablokuję go, to jak pogodzić zmiany, których zmiany należy zaakceptować? Wiąże się to z sytuacją w 1, ponieważ użytkownik 1 może przesłać dane, a zanim użytkownik 2 otrzyma zaktualizowane dane, być może poszedł naprzód i przesłał zmiany.

Naprawdę szukam wskazówek, porad lub wskazówek dotyczących prawidłowej synchronizacji danych między wieloma instancjami tej aplikacji internetowej. Byłbym bardzo wdzięczny!

Myślę, że tablica będzie twoim wyborem dla nr 1, powinieneś publikować zmiany w zadaniach (lub innych udostępnionych danych) we wspólnym miejscu, aby wszystkie zainteresowane strony mogły je zobaczyć i DTRT.

W przypadku nr 2 należy przyjrzeć się optymistycznemu blokowaniu . Zasadniczo musisz oznaczyć czasowo wszystkie swoje edytowalne rekordy ostatnim czasem aktualizacji. Podczas próby zapisania rekordu należy najpierw sprawdzić, czy rekord w bazie danych ma ten sam czas ostatniej aktualizacji, co rekord. Jeśli nie, oznacza to, że ktoś zaktualizował rekord, a teraz musisz albo pobrać zaktualizowany rekord i poinformować użytkownika, że ​​musi ponownie wprowadzić zmiany, lub możesz spróbować scalić zmiany użytkownika w zaktualizowanym rekordzie (co zwykle okazuje się być proste lub niemożliwe).

Wymyśliłem projekt aplikacji komputerowej (który jeszcze nie został w pełni przetestowany) z podobnymi wymaganiami, które mogą być pomocne.

Moje rozwiązanie polegało na zastosowaniu wzorca MVC (z jednym modelem, ale wieloma kontrolerami i widokami), w którym każdy kontroler wprowadzał zmiany w modelu za pomocą transakcji (przy użyciu STM ), a gdy transakcja została zatwierdzona, model nadał powiadomienie o aktualizacji do widoków ).

Każdy klient również śledził wszystko, co jest aktualizowane lokalnie, ale kiedy te aktualizacje lokalne zostały zakończone (tj. Wysłane w celu zatwierdzenia), powróciło do korzystania z informacji zawartych w modelu.

Miałem też stos cofania ze wszystkimi zmianami wprowadzonymi przez użytkowników, aby można było przywrócić rzeczy.

Może to nie być najlepszy model dla aplikacji internetowej, ponieważ Model musiał transmitować zmiany w widokach, co może nie być najłatwiejszym w / w klientem internetowym.

dla 1. powinieneś zobaczyć, czy wzór publikowania / subskrybowania jest bardziej odpowiedni.
dla 2. zależy to od twojej sytuacji:

• jak często będzie taka sytuacja?
• jak zła jest sytuacja, w której jeden z Twoich użytkowników nie będzie mógł zaktualizować zadania, ponieważ jest ono zablokowane lub ktoś inny go zmienił w międzyczasie?
  osobiście wolę podejście (stosowane np. w pivotaltracker ), w którym są:
  • bez zamków,
  • widzisz wszystkie zmiany w czasie rzeczywistym, i
  • interfejs użytkownika zachęca do częstych drobnych aktualizacji zamiast większych na wiele atrybutów.
  • przechowujecie historię wszystkich dokonanych zmian. jeśli historia jest widoczna dla użytkowników, ewentualne konflikty lub nadpisania można rozwiązać za pomocą komentarzy, adnotacji lub wiadomości.

• Zablokuj rekord. Nie jest to preferowane, ponieważ zmniejszy współbieżność, a rekord może zostać zablokowany na dłużej niż to konieczne.
• Ostatni do przesłania zastępuje inne jednoczesne zmiany. Użytkownicy tego nie chcą. Niektóre programy takie jak JIRA to robią. https://community.atlassian.com/t5/Jira-questions/Edit-a-JIRA-Issue-at-the-same-time-by-two-Users-result-in-last/qaq-p/389243
• Jednoczesne zmiany. Wniosek powinien przesłać tylko zmienione pola rekordu. W ten sposób zapobiegniesz konfliktom. Większość oprogramowania wiki może łączyć zmiany w tym samym polu tekstowym, jeśli nie ma konfliktów: /programming/3411888/how-does-a-wiki-handle-multiple-simultaneous-edits Zobacz na przykład MediaWiki, ponieważ umożliwia jednoczesne edycje i ma dobry interfejs użytkownika w przypadku konfliktów: https://www.mediawiki.org/wiki/Extension:TwoColConflict

Radzę, aby nigdy nie blokować i nie zgłaszać konfliktu, jeśli tak się stanie.

Proszę spojrzeć na:

https://github.com/spring-projects/spring-petclinic/issues/433

Możesz zobaczyć film i przykładowy kod.

Czy to spełni twoje wymagania?