СЕ
Не совсем поняла вопрос
ну у вас что-то меняется в объекте разными потоками, а если сбой или еще что нибудь, откат изменений возможен ?
Size: a a a
2020 December 03
СЕ
нет, в БД тоже много чего хранится. Просто много проверок делается до того как до БД дело доходит и это занимает время
может быть кешировать этот объект где нибудь?
AS
Всем привет. У меня вопрос про то как лучше реализовывать защиту от параллельной модификации объектов.
Например, в интерпрайз приложении есть сложный объект у которого в свою очередь атрибуты - это другие объекты и тд. У многих пользователей есть возможность модифицировать этот объект. Вопрос в том, как избежать одновременной модификации несколькими пользователями?
Я понимаю что нет ничего “одновременного” и что на уровне БД уже есть защита от параллельной модификации и все изменения станут в очередь.
Но если нам нужно на это все накрутить еще какую-то бизнес логику и например делать проверку чего угодно (прав, доступного количества и тд), то эта транзакция (модификации) может занимать значительное время.
Есть ли у спринга готовые решения данной проблемы? Или как вообще к ней подойти? Посоветуйте пжл что почитать по теме
Например, в интерпрайз приложении есть сложный объект у которого в свою очередь атрибуты - это другие объекты и тд. У многих пользователей есть возможность модифицировать этот объект. Вопрос в том, как избежать одновременной модификации несколькими пользователями?
Я понимаю что нет ничего “одновременного” и что на уровне БД уже есть защита от параллельной модификации и все изменения станут в очередь.
Но если нам нужно на это все накрутить еще какую-то бизнес логику и например делать проверку чего угодно (прав, доступного количества и тд), то эта транзакция (модификации) может занимать значительное время.
Есть ли у спринга готовые решения данной проблемы? Или как вообще к ней подойти? Посоветуйте пжл что почитать по теме
Давайте на примере. Пусть будет таблица T с ключем K и неким атрибутом A. Открыли форму на редактирование. Сохранили в Aold значение атрибута A, отредактировали A, получили Anew.
Как определить при сохранении конфликт с другими пользователями?
Этот запрос обновит 1 запись, если не было конфликта, и 0, если кто-то уже изменил значение атрибута A, и надо предложить пользователю получить актуальные данные.
Как-то так
Как определить при сохранении конфликт с другими пользователями?
update T set A = Anew where K = Key and A = Aold
Этот запрос обновит 1 запись, если не было конфликта, и 0, если кто-то уже изменил значение атрибута A, и надо предложить пользователю получить актуальные данные.
Как-то так
AE
Давайте на примере. Пусть будет таблица T с ключем K и неким атрибутом A. Открыли форму на редактирование. Сохранили в Aold значение атрибута A, отредактировали A, получили Anew.
Как определить при сохранении конфликт с другими пользователями?
Этот запрос обновит 1 запись, если не было конфликта, и 0, если кто-то уже изменил значение атрибута A, и надо предложить пользователю получить актуальные данные.
Как-то так
Как определить при сохранении конфликт с другими пользователями?
update T set A = Anew where K = Key and A = Aold
Этот запрос обновит 1 запись, если не было конфликта, и 0, если кто-то уже изменил значение атрибута A, и надо предложить пользователю получить актуальные данные.
Как-то так
Optimistic locking на основе версионирования решает проблему
AE
Все есть из коробки
AE
Вижу стоило девушке задать вопрос и чат оживился)
AS
Optimistic locking на основе версионирования решает проблему
Я привел пример, как имея только чистый SQL можно подходить к проблеме конфликтов
AE
нет, в БД тоже много чего хранится. Просто много проверок делается до того как до БД дело доходит и это занимает время
Так много чего или все? Какие проверки? Валидации данных? Все это мало соотносится к конкурентной модификации
AS
Вижу стоило девушке задать вопрос и чат оживился)
"Нам это только давай" (с)
AE
Я привел пример, как имея только чистый SQL можно подходить к проблеме конфликтов
А теперь представим что полей пора десятков, а ещё вложенные зависимости
AS
А теперь представим что полей пора десятков, а ещё вложенные зависимости
Поэтому чаще всего используют грубый detect конфликта на основе timestamp
AS
Но вот если надо определить конфликт на уровне конкретных полей, то способ я описал выше.
AE
Поэтому чаще всего используют грубый detect конфликта на основе timestamp
Это плохой подход. Может быть несколько продуктов за один таймстамп. Колонка с версией же на каждый апдейт инкрементируется. Даже больше, это делает за нас, например, хибер
AS
Так, а где же героиня?
AE
Но вот если надо определить конфликт на уровне конкретных полей, то способ я описал выше.
Такой необходимости не бывает, обычно на запись в таблице полностью
K
Optimistic или pessimistic locking
о и вправду забыла об этом, спасибо
AE
Так, а где же героиня?
Вестимо читает диалог)
AS
Такой необходимости не бывает, обычно на запись в таблице полностью
Я в своих фоксовских базах на заре этого века как раз эти конфликты на уровне полей решал
K
Дмитрий
зависит от архитектура приложения. Поскольку врядли приложение задеплоено на 1 инстанс то читайте про распределенные блокировки - redis, zookeeper
да, приложение не в одном экземпляре. Что-то типа этого почтитать https://redis.io/topics/distlock
AE
Я в своих фоксовских базах на заре этого века как раз эти конфликты на уровне полей решал
Сейчас так не делают ибо никто не оперирует изменениями конкретных полей конкретных таблиц