Здравствуйте.
Необходимо мнение сообщества и по данной задаче.
Дано:
Веб-приложение. Серверная часть на Java. Клиенты подключаются с помощью стандартного браузера и производят операции над данными. Число клиентов – до 5000. Операции – просмотр (поиск, сортировка, фильтрация), создание, удаление, изменение записей. Данные находятся в реляционной БД.
Возможны ситуации, когда более чем один пользователь вносит изменения в один объект модели данных.
Эти изменения могут быть не конфликтующими (пользователи изменяют разные поля и это не нарушает целостность данных) и конфликтующими (пользователи изменяют одно и то же поле(поля) или же разные поля с нарушением целостности данных или связанные поля разных объектов так же с нарушением целостности).
Задача:
Реализовать подсистему обнаружения и разрешения коллизий в веб-приложении с высокой эффективностью, минимальными затратами на передачу данных между клиентом и сервером и минимальным эффектом на производительности клиентской и серверной части.
Вопросы:
1. Стандартные / распространённые / общепринятые способы разрешения таких коллизий в веб-приложениях
2. Существующие реализации этих способов в продуктах / фреймворках / библиотеках и т.п.
Здравствуйте, Orgy243, Вы писали:
O>Здравствуйте. O>Необходимо мнение сообщества и по данной задаче.
O>Дано: O>Веб-приложение. Серверная часть на Java. Клиенты подключаются с помощью стандартного браузера и производят операции над данными. Число клиентов – до 5000. Операции – просмотр (поиск, сортировка, фильтрация), создание, удаление, изменение записей. Данные находятся в реляционной БД.
O>Возможны ситуации, когда более чем один пользователь вносит изменения в один объект модели данных. O>Эти изменения могут быть не конфликтующими (пользователи изменяют разные поля и это не нарушает целостность данных) и конфликтующими (пользователи изменяют одно и то же поле(поля) или же разные поля с нарушением целостности данных или связанные поля разных объектов так же с нарушением целостности).
Если Вы все запросы к бд оборачиваете в транзакции с уровнем изоляции readcommitted, целостность базы у Вас не нарушится.
On 09.12.2015 12:08, Orgy243 wrote:
> Задача: > Реализовать подсистему обнаружения и разрешения коллизий в > веб-приложении с высокой эффективностью, минимальными затратами на > передачу данных между клиентом и сервером и минимальным эффектом на > производительности клиентской и серверной части.
Отлично работает JPA Optimistic Locking.
Реализации есть во всех JPA-совместимых ORM (Hibernate, EclipseLink), ну
или можно просто идею использовать, она очень простая.
Стратегии merge при обнаружении конфликта — тут надо смотреть на
требования.
Здравствуйте, Qulac, Вы писали:
Q>Если Вы все запросы к бд оборачиваете в транзакции с уровнем изоляции readcommitted, целостность базы у Вас не нарушится.
Если readcommitted, то нарушится легко и непринужденно. Не нарушится, если serializable, но обычно это слишком жестко.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Qulac, Вы писали:
Q>>Если Вы все запросы к бд оборачиваете в транзакции с уровнем изоляции readcommitted, целостность базы у Вас не нарушится. IB>Если readcommitted, то нарушится легко и непринужденно. Не нарушится, если serializable, но обычно это слишком жестко.
Почему? Топикастер как я понял биться, что может нарушится целостность бд, а она не может нарушиться, так как бд переходит из одного согласованного состояния в другое. Несогласованность чтения это уже другая проблема.
O>Вопросы: O>1. Стандартные / распространённые / общепринятые способы разрешения таких коллизий в веб-приложениях
O>2. Существующие реализации этих способов в продуктах / фреймворках / библиотеках и т.п.
O>3. На чем лучше реализовать данную систему.
Строго говоря, это в форум архитектуры, а не БД. У баз, конечно, есть встроенная поддержка конкурентного доступа, но это уровень ниже.
Сначала вам надо понять, какие именно структуры данных конфликтуют и попробовать развести их на уровне логики приложения.
Есть разные стратегии в зависимости от структуры данных, характера нагрузки и требованиям к целостности...
Здравствуйте, Qulac, Вы писали:
Q>Почему? Топикастер как я понял биться, что может нарушится целостность бд, а она не может нарушиться, так как бд переходит из одного согласованного состояния в другое. Несогласованность чтения это уже другая проблема.
Несогласованное чтение может быть использовано для записи новых данных, таким образом и получаются несогласованная запись, при формальном соблюдении требований RC, RR и даже Snapshot.
Есть разные проявления этого эффекта от Phantom до Write Skew.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Qulac, Вы писали:
Q>>Почему? Топикастер как я понял биться, что может нарушится целостность бд, а она не может нарушиться, так как бд переходит из одного согласованного состояния в другое. Несогласованность чтения это уже другая проблема. IB>Несогласованное чтение может быть использовано для записи новых данных, таким образом и получаются несогласованная запись, при формальном соблюдении требований RC, RR и даже Snapshot. IB>Есть разные проявления этого эффекта от Phantom до Write Skew.
Это уже нужно разрешать "ручками" в соответствии с тз.
Здравствуйте, Qulac, Вы писали:
Q>Если Вы все запросы к бд оборачиваете в транзакции с уровнем изоляции readcommitted, целостность базы у Вас не нарушится.
Очень неоднозначное заявление. Что имеется в виду под целостностью базы? То, что из нее данные можно прочитать? Так тут любой уровень транзакций подойдет, можно даже вообще без них обойтись, СУБД все равно гарантирует целостность базы.
На практике, чтение-редактирование-запись данных в большинстве случаев невозможно произвести в рамках одной транзакции. Безопасность параллельного редактирования достигается пессимистичными и оптимистичными блокировками для определения конфликта редактирования. Какую из них следует использовать может подсказать только анализ бизнес-требований. После определения конфликт надо разрешить, эта задача тоже не имеет универсального рецепта.
Здравствуйте, Qulac, Вы писали:
Q>Это уже нужно разрешать "ручками" в соответствии с тз.
Что противоречит вашему тезису "Если Вы все запросы к бд оборачиваете в транзакции с уровнем изоляции readcommitted, целостность базы у Вас не нарушится."
Всё решается просто. Введите версионирование записи. И при внесении сверяйте текущую версию с той, которая есть в базе. При чём даже "откат состояния" — это всегда будет новая версия. И тогда вам придётся просто сделать одну дополнительную проверку "на версию" в транзакции и в зависимости от результата — либо сменить состояние на новое (при этом в триггере можно делать инкремент версии), либо прочитать "более новое", проанализировать различие и разрулить конфликты (дать пользователю ручками подтвердить/автоматом, если поля другие затронуты, что-то ещё).
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Qulac, Вы писали:
Q>>Если Вы все запросы к бд оборачиваете в транзакции с уровнем изоляции readcommitted, целостность базы у Вас не нарушится.
Z>Очень неоднозначное заявление. Что имеется в виду под целостностью базы? То, что из нее данные можно прочитать? Так тут любой уровень транзакций подойдет, можно даже вообще без них обойтись, СУБД все равно гарантирует целостность базы.
Подойдет любой, но readcommitted дает возможность считывать целостные данные, т.е. с точки зрения пользователя, она будет оставаться целостной, более низкий уровень изоляции не даст такого эффекта.
Z>На практике, чтение-редактирование-запись данных в большинстве случаев невозможно произвести в рамках одной транзакции. Безопасность параллельного редактирования достигается пессимистичными и оптимистичными блокировками для определения конфликта редактирования. Какую из них следует использовать может подсказать только анализ бизнес-требований. После определения конфликт надо разрешить, эта задача тоже не имеет универсального рецепта.
Это мы знаем, для этого и различают бизнес — тразнзакции и системные транзакции.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Qulac, Вы писали:
Q>>Это уже нужно разрешать "ручками" в соответствии с тз. IB>Что противоречит вашему тезису "Если Вы все запросы к бд оборачиваете в транзакции с уровнем изоляции readcommitted, целостность базы у Вас не нарушится."
Я не вижу тут противоречий, мы просто о разных вещах говорим.
Мы уже победили, просто это еще не так заметно...
