Как использовать 2LC и не повторять SQL-запрос в Hibernate, когда в базе данных нет строки

Может ли кэш второго уровня Hibernate (2LC) выполнять кеширование для не найденных записей в базе данных?

Я запрашиваю объект Account по первичному ключу accountNumber - он настроен как @Cachable. Если я выполню em.find ('AA') в первый раз, то спящий режим проверит 2LC, он пропущен в 2LC, тогда будет выполнен SQL-запрос. В БД нет учетной записи AA, поэтому вызов em.find возвращает значение null.

Если я выполню em.find ('AA') второй раз в другой транзакции, то спящий режим снова выполнит SQL-запрос, даже если SQL был выполнен раньше.

Возможно ли, что Hibernate сохранит null из первого выполненного запроса, поэтому другой SQL не потребуется до тех пор, пока ключ AA не будет аннулирован в кеше?

Я использую EAP 6.2.4, Hibernate 4.2.7, Infinispan 5.2.7


hibernate infinispan second-level-cache
person kodstark    schedule 20.02.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Нет. Даже с Hibernate ORM 5.x, 2LC API не включает это, и реализация 2LC не может возвращать намек на то, что объект не может быть в БД (даже если реализация может содержать какую-то надгробную плиту). и знаю это).

Поскольку иногда это может быть весьма полезно, зарегистрируйте JIRA с запросом функции.

person Radim Vansa    schedule 22.02.2016
comment
Спасибо. Я также знаю о кеше запросов, который собираюсь использовать в моем случае. Я предпочел использовать 2LC с первичным ключом, чтобы мое приложение меньше зависело от SQL и было ближе к запросам по первичному ключу для тестирования производительности против 1LC после изменения DAO. - person kodstark; 23.02.2016
comment
Да, но кеш запросов оказывает некоторое влияние на производительность, а также есть короткое окно, когда он может предоставить устаревший результат. - person Radim Vansa; 23.02.2016
comment
Можете ли вы объяснить большее влияние на производительность использования кеша запросов? В моем случае я использую сущности, обновляемые раз в день, поэтому кеш запросов не будет часто становиться недействительным. Устаревшие результаты? Было бы неплохо, если бы у вас была ссылка, объясняющая это. - person kodstark; 23.02.2016
comment
Хорошо, влияние на производительность сказывается только на записи, так как 2LC необходимо обновить метку времени последней записи данного типа объекта. И устаревание происходит только в кластерном режиме, поскольку обновления меток времени по умолчанию распространяются асинхронно. См. документы .jboss.org / hibernate / orm / 5.1 / userguide / html_single / (информационное окно и абзац ниже) - person Radim Vansa; 24.02.2016
comment
Я связал документы 5.1, но часть о кешировании запросов сохраняется и для 4.2 (+ в 4.2 есть несколько ошибок). - person Radim Vansa; 24.02.2016