Ответ 1
Я просмотрел раздел 3.4.4 Режимы блокировки Java Persistence API 2.0 Final Release, и пока я ничего не нашел (он не указывает, что это значение по умолчанию или что-то в этом роде) есть сноска, в которой говорится следующее.
Тип режима блокировки NONE может быть указан как значение режима блокировки аргументы, а также предоставляет значение по умолчанию для аннотаций.
Раздел посвящен типам LockModeType
доступных значений и их обычаям и описывает, какие методы принимают аргумент такого рода и еще много чего.
Итак, как сказано LockModeType.NONE
по умолчанию для аннотаций (JPA, аннотации слева и справа), я думаю, когда вы используете EntityManager.find(Class, Object)
, используется значение по умолчанию LockModeType
.
Есть несколько других тонких намеков, чтобы укрепить это. Раздел 3.1.1 Интерфейс EntityManager.
Метод поиска (при условии, что он вызывается без блокировки или вызван LockModeType.NONE), и метод getReference не требуется вызывается в контексте транзакции.
Это имеет смысл. Например, если вы используете MySQL как свою базу данных, а ваш механизм базы данных по выбору - InnoDB, то (по умолчанию) ваши таблицы будут использовать REPEATABLE READ
, если вы используете некоторые другие СУБД или другие механизмы базы данных, которые могут измениться.
В настоящее время я не совсем уверен, что уровни изоляции имеют какое-либо отношение к режимам блокировки JPA (хотя кажется, что это так), но я хочу сказать, что разные системы баз данных отличаются, поэтому JPA не может решить для вас (по крайней мере согласно спецификации), какой режим блокировки использовать по умолчанию, поэтому он будет использовать LockModeType.NONE
, если вы не укажете его иначе.
Я также нашел статью об уровнях изоляции и режимах блокировки, вы можете прочитать ее.
О, и ответить на ваш последний вопрос.
Если мы не определяем явный режим блокировки, может ли база данных целостность будет потеряна?
Это зависит, но если у вас есть параллельные транзакции, то ответ, вероятно, да.