В настоящее время мы используем 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
). Любая другая параллельная транзакция, пытающаяся получить доступ к одной и той же записи, будет приостановлена до тех пор, пока блокировка не будет удалена. Эта стратегия дает лучшую предсказуемость по цене исполнения и не масштабируется бесконечно.
Ссылки
- Справочное руководство по Hibernate Core
Ответ 2
Существуют JPA-реализации, такие как objectDB, в которых оптимистическая блокировка активируется по умолчанию, и пользователю не нужно поддерживать переменную версии в таблице базы данных, поскольку она внутренне заботится об объектеDB. Оптимистическая блокировка хороша там, где обновления не часто встречаются, и когда блокировка имеет неявные затраты, например, в электронной коммерции, где блокировка означает потерю бизнеса. Пессимистическая блокировка идеальна там, где concurrency не востребована, а транзакция завершена быстро, чтобы освободить ресурс.
Ответ 3
Существует некоторая документация о сеансах и транзакциях в вики-сообществе Hibernate. В конечном итоге он обрабатывается основными транзакциями RDBMS, но вам нужно обратить внимание на жизненный цикл объектов, загруженных или сохраненных.
Ответ 4
Hibernate обрабатывает версию самостоятельно, здоровое предложение состоит в том, чтобы не изменять номер версии вообще.