Як ви обробляєте кілька користувачів, що редагують один і той самий фрагмент даних у веб-програмі?

Над проектом я працюю над тим, щоб надрукувати веб-додаток, який керуватиме списком завдань між кількома користувачами. Це головний список завдань, елементи завдань якого розповсюджуються авторизованим користувачем. У кожного користувача є свій власний обліковий запис для входу та перегляду завдань, які їм призначені; можна для декількох користувачів мати одне загальне завдання.

Я намагаюся залишити деталі проекту поза цим, оскільки я більше розуміюсь із загальною концепцією того, як впоратися з наступними ситуаціями, але якщо це допомагає, я використовую Java, EclipseLink та GWT з реалізованою RequestFactory. База даних - PostgreSQL.

Отже, концептуальні проблеми, які я намагаюся примирити, такі:

1. Якщо окреме завдання, яке є загальним для кількох користувачів, зміниться будь-яким чином, наприклад, завдання виконано, видалено тощо, список завдань для всіх користувачів, які мають це завдання, буде оновлений. Які існують шаблони дизайну, які допомагають реалізувати цю функцію?

   • Деякі зразки, які я переглянув, - це "Спостерігач" і "Посередник" - чи існують інші, які слід враховувати?

2. Скажімо, два користувачі одночасно змінюють одне і те ж завдання.

   • По-перше, я повинен дозволити, щоб така ситуація сталася, чи слід накладати на неї замок, поки одна чи інша людина не зробить змін?

   • По-друге, якщо я не ставлю замок, як я погоджую чиї зміни приймати? Це пов'язано з ситуацією в 1, оскільки користувач 1 може подати дані, і перш ніж користувач 2 отримає оновлені дані, він / вона, можливо, пішов вперед і подав свої зміни.

Я дійсно шукаю будь-які орієнтири, поради чи поради, які можна надати, як правильно синхронізувати дані між кількома примірниками цього веб-додатка. Я б дуже цінував це!

Я думаю, що Біла дошка стане вашим шаблоном вибору для №1, ви повинні розміщувати зміни до завдань (або інших спільних даних) у загальному місці, щоб усі зацікавлені сторони могли їх бачити та DTRT.

Для №2 потрібно дивитися на оптимістичне блокування . По суті, потрібно позначити всі свої редаговані записи за останній час оновлення. Коли ви намагаєтесь зберегти запис, спочатку переконайтеся, що запис у базі даних має таку ж останню оновлену часову позначку, що і ваша запис. Якщо ні, то хтось оновив запис, і тепер вам доведеться або отримати оновлений запис, і повідомити користувача, що їм потрібно ввести свої зміни ще раз, або ви можете спробувати об'єднати зміни користувача з оновленим записом (що, як правило, виявляється бути простим або неможливим).

Я придумав дизайн для настільного додатка (який ще не пройшов повну перевірку) із подібними вимогами, які можуть бути корисними.

Моє рішення полягало в застосуванні шаблону MVC (з єдиною моделлю, але декількома контролерами та переглядами), коли кожен Контролер вносив зміни до Моделі за допомогою транзакцій (використовуючи STM ), і коли транзакція здійснена, Модель передала сповіщення про оновлення для Перегляду (s) ).

Кожен клієнт також відслідковував що-небудь, що оновлюється локально, але коли ці локальні оновлення були закінчені (тобто надсилаються для здійснення), він повернувся до використання базової інформації Моделі.

У мене також був скасований стек із усіма змінами, які користувачі внесли, щоб змінити речі.

Це може бути не найкращою моделлю для веб-програми, хоча, оскільки Модель мусила транслювати зміни в Перегляди, що може бути не найпростішим для веб-клієнта.

для 1. ви повинні побачити, чи краще підходить модель публікації / підписки .
для 2. це залежить від вашої ситуації:

• наскільки часто ця ситуація буде?
• наскільки погана ситуація, коли один з ваших користувачів не зможе оновити завдання, оскільки він заблокований або хтось ще змінив його тим часом?
  особисто я віддаю перевагу підходу (застосовується, наприклад, у зворотному трекері ), в якому є:
  • немає замків,
  • ви бачите всі зміни в режимі реального часу та
  • користувальницький інтерфейс запрошує робити часті незначні оновлення замість великих на декілька атрибутів.
  • ви зберігаєте історію всіх внесених змін. якщо історію бачать користувачі, з часом виниклі конфлікти чи перезаписи можна вирішити за допомогою коментарів, приміток чи повідомлень.

• Блокування запису. Це не є кращим, оскільки це зменшить паралельність, а запис може бути заблокований більше часу, ніж потрібно.
• Останнє для надсилання замінює інші супутні зміни. Користувачі цього не хочуть. Це робить таке програмне забезпечення, як JIRA. https://community.atlassian.com/t5/Jira-questions/Edit-a-JIRA-Issue-at-the-same-time-by-two-Users-result-in-last/qaq-p/389243
• Одночасне редагування Додаток повинен подавати лише поля запису, які змінюються. Таким чином ви запобігаєте конфліктам. Більшість програм вікі можуть об'єднати зміни в одне текстове поле, якщо немає конфліктів: /programming/3411888/how-does-a-wiki-handle-multiple-sim istovremeno- edits Дивіться, наприклад, MediaWiki як це дозволяє одночасно редагувати та мати хороший інтерфейс користувача у разі конфліктів: https://www.mediawiki.org/wiki/Extension:TwoColConflict

Моя рекомендація - ніколи не блокувати та повідомляти про конфлікт, якщо він трапився.

Погляньте, будь ласка, на:

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

Ви можете побачити відео та зразок коду.

Чи відповідає це вашим вимогам?