Как вы обрабатываете / реагируете на параллелизм пользовательского ввода на уровне GUI?

Question

Каковы хорошие способы обработки параллельного ввода данных пользователем?

Поскольку ответы на этот вопрос уже исключают блокировку базы данных, как вы обрабатываете одновременные пользовательские вводы в целом?

Блокировка всегда плохая идея, даже если она не реализована блокировкой строк? Существуют ли лучшие практики, которые не зависят от варианта использования? Какой у вас был опыт с вашими стратегиями?

РЕДАКТИРОВАТЬ: Мне известно об обработке параллелизма на уровне данных с помощью транзакций: если два пользователя одновременно запускают сложное изменение данных, транзакция будет обрабатывать его.

Но мне интересно работать с ними или хотя бы реагировать на них на уровне графического интерфейса. Что если изменение данных является частью длительной операции с взаимодействием с пользователем?

Допустим, два или более пользователей редактируют один и тот же файл через веб-интерфейс. В какой-то момент один из пользователей нажимает кнопку сохранения. Что радует других пользователей?

• Получат ли они уведомление и / или будут ли они вынуждены перезагрузиться? Или в конечном итоге будут перезаписаны изменения первого пользователя?
• Должен ли я заблокировать файл и запретить нескольким пользователям редактировать один и тот же файл?
• Могу ли я поместить весь процесс редактирования в транзакцию (я очень сомневаюсь в этом, но кто знает ...)

Каков наилучший способ справиться с этой и аналогичными ситуациями? Есть ли другие стратегии?

Answer 1

Наилучшая стратегия зависит от того, что должно произойти с точки зрения (бизнес) процесса - также важны вопросы о том, чего обычно ожидают пользователи и что их меньше всего удивит, и, конечно, возможно ли это реализовать что они ожидают.

Ваш пример редактирования файла через Интернет можно разбить следующим образом:

1. пользовательские чеки out / gets / downloads / открывает файл v0
2. проверка user2 out / gets / downloads / открывает файл v0
3. пользователь1 вносит изменения в свою копию файл v0
4. user2 вносит изменения в свою копию файл v0
5. пользователь1 сохраняет версию файла v1 на сервер
6. user2 сохраняет версию файла v2 на сервере

Обратите внимание, что для веб-приложений и действительно для обычных настольных офисных программ характерно, что новейшие изменения, которые вносит пользователь, становятся доступными (для других) только после их сохранения, что означает, что это не тот случай, когда печатный текст коллеги появляется поверх вашей копии файла, который вы редактируете.

Классический подход к управлению версиями заключается в том, что для пользователя1 ничего не меняется по сравнению с обычным процессом редактирования / сохранения на рабочем столе.

Однако для user2, когда он пытается сохранить v2 на сервере, приложение должно проверить, не было ли каких-либо изменений в версии файла v0 с момента последней загрузки пользователем. Поскольку дело обстоит именно так, система контроля версий обычно показывает ему обе версии (v1 и v2) на экране рядом друг с другом, и он может смешивать их и сохранять полученную версию (v3) на сервере.

Для текстовых файлов в Unix и Windows существует ряд инструментов и систем, которые пытаются автоматизировать процесс, чтобы, если области редактируемого файла не перекрывались, изменения автоматически объединялись.

Альтернативой является блокировка файла для user2 до тех пор, пока user1 не закончит его редактирование.

Внесение редактирования в транзакцию обычно неактуально. Это последняя операция, которая пытается перезаписать существующий файл новой версией, это важно. Редактирование происходит независимо на каждой рабочей станции пользователя и не затрагивает сервер до последней точки (сохранение).

---

Кстати, ваш пример заметно отличается от другой ситуации, такой как бронирование авиабилетов или запись на прием к врачу.

При бронировании билетов количество мест в самолете ограничено. Возможно, из-за того, что передача данных фактически не является мгновенной для более чем одного человека, чтобы забронировать место на одно и то же последнее место в самолете.

Поэтому бронирование должно быть как минимум двухэтапным:

1. система показывает свободные слоты;
2. пользователь запрашивает один из свободных слотов (S1);
3. система сообщает пользователю, есть ли слот действительно все еще свободен, и если так, оставляет за собой.
4. пользователь завершает бронирование.

Шаг "действительно все еще свободен" заключается в том, что информация о пользовательских представлениях веб-страницы обычно не обновляется в реальном времени, поэтому между шагами 1 и 2 возможно, что другой пользователь подал заявку на свободный слот.

Answer 2

Посмотрите, как обрабатывать «транзакции» на любом используемом вами языке / API базы данных. Если вы спроектируете это правильно, он справится с вами.

И чтобы понять теорию, я бы порекомендовал Распределенные системы от Couloris et al , но есть много других хороших книг.