Параллельная обработка обновлений в спящем режиме

В настоящее время мы используем JDBC в слое данных и планируем заменить его на спящий режим. Я новичок в Hibernate и не знаю, как hibernate обрабатывает concurrency. Может кто-нибудь объяснить мне, если мы будем использовать spring для управления транзакциями, как будут обрабатываться параллельные обновления: с помощью hibernate (в автоматическом управлении версией памяти в спящем режиме), или мне нужно поместить столбец версии в базу данных, чтобы заботиться о параллельных обновлениях вручную.

Ответы

Ответ 1

Может кто-нибудь объяснить мне, если мы используем spring для управления транзакциями, как одновременные обновления будут обрабатываться с помощью hibernate (в автоматическом управлении версией памяти в спящем режиме), или я должен поместить столбец версии в базу данных, чтобы заботиться о параллельных обновления вручную.

Используете ли вы spring для управления транзакциями или нет, это не имеет особого значения и не имеет значения, когда дело доходит до управления concurrency, это фактически обрабатывается Hibernate. Hibernate может использовать 2 стратегии для обработки параллельных обновлений: оптимистичная блокировка и пессимистическая блокировка.

Оптимистичный

При использовании оптимистической блокировки вы сопоставляете специальный атрибут (число, временную метку) в качестве версии (так что у вас на самом деле есть столбец для него). Эта версия считывается при получении объекта и включается в предложение where во время обновления и увеличивается с помощью Hibernate.

Чтобы проиллюстрировать, как это работает, представьте, что вы загружаете объект Person с помощью id = 1 и текущей версией = 1. После сохранения Hibernate выполнит что-то вроде этого:

update PERSON set ID=1, NAME='NAME 1', VERSION=2 where ID=1 and VERSION=1;

Итак, теперь представьте, что вы выполняете две параллельные транзакции, каждая из которых загружает объект тот же (тот же номер версии) и меняет имя.

Предположим, что первая транзакция № 1 выполнена, выполняется следующий запрос:

update PERSON set ID=1, NAME='NAME 1', VERSION=2 where ID=1 and VERSION=1;

Успешно, и версия увеличивается.

Затем транзакция № 2 выполняется, выполняется следующий запрос:

update PERSON set ID=1, NAME='NAME 2', VERSION=2 where ID=1 and VERSION=1;

Этот ничего не будет обновлять, потому что предложение where не будет соответствовать какой-либо записи. Здесь вы получите оптимистическое исключение concurrency.

Эта стратегия подходит, если вы не поддерживаете соединение, когда одновременный доступ не часто встречается и очень хорошо масштабируется. И все, конечно, обрабатывается прозрачно Hibernate для вас, пока вы сопоставляете атрибут версии.

Пессимистический

При использовании пессимистической блокировки Hibernate блокирует запись для вашего эксклюзивного использования до тех пор, пока вы не закончите с ней (обычно с помощью SELECT ... FOR UPDATE). Любая другая параллельная транзакция, пытающаяся получить доступ к одной и той же записи, будет приостановлена ​​до тех пор, пока блокировка не будет удалена. Эта стратегия дает лучшую предсказуемость по цене исполнения и не масштабируется бесконечно.

Ссылки

Ответ 2

Существуют JPA-реализации, такие как objectDB, в которых оптимистическая блокировка активируется по умолчанию, и пользователю не нужно поддерживать переменную версии в таблице базы данных, поскольку она внутренне заботится об объектеDB. Оптимистическая блокировка хороша там, где обновления не часто встречаются, и когда блокировка имеет неявные затраты, например, в электронной коммерции, где блокировка означает потерю бизнеса. Пессимистическая блокировка идеальна там, где concurrency не востребована, а транзакция завершена быстро, чтобы освободить ресурс.