Некоторые пояснения о механизме кэширования Hibernate?

Question

У меня есть вопросы по поводу утверждений, которые я нашел во время прохождения урока кэширования в спящем режиме.

Statement1: -Кэш первого уровня всегда ассоциируется с объектом Session. Hibernate использует этот кеш по умолчанию.

Вопрос1: -
Поскольку этот кэш по умолчанию содержит все результаты таких методов сеанса, как загрузка, получение и т. Д. Не будет ли это серьезной проблемой с памятью из-за удержания всех объектов в видении?

Вопрос2: -
Нужно ли включать этот кеш или его там по умолчанию? Можно ли отключить кэш первого уровня, если я хочу? Если да, то как?

Ниже приведены вопросы как для кэша первого уровня, так и для кэша второго уровня

Вопрос3: -
Если я получу один и тот же объект из кэша (скажем, я загружаю объект customer с обычным значением 1 дважды в одном сеансе), оба объекта, возвращенные из кэша, будут иметь разные ссылки на объект, лежащий в кэше. Правильно? Потому что, если я обновлю какое-то поле в объекте customer, оно не будет отображаться в кэше до тех пор, пока не будет вызван метод сохранения / обновления.

Вопрос4: -
Насколько я понимаю, если мы попытаемся получить объект customer с идентификатором 1 во второй раз из этого кэша, он вернет тот же старый объект, даже если он был обновлен между ними. Как мы можем гарантировать, что если оно обновлено, оно считывает данные из базы данных, иначе из кэша? Я думаю, мы можем использовать стратегию чтения-записи с кэшем с классом, подобным EHCache

Вопрос5: - Кэширование запросов
Я прочитал это утверждение: -Обновления в запросах происходят очень часто. Таким образом, для кэширования запросов необходимы две области кэша.

Для сохранения результатов (значения идентификатора кэша и результаты только для типа значений). Для хранения самых последних обновлений.

Я думаю, что «обновления в запросах происходят очень часто» означает, что здесь мы обычно меняем какое-то значение параметра, например select * from customer where custid=? Так что id будет изменено для другого идентификатора клиента. Таким образом, кеш запросов будет хранить каждый запрос (вместе с параметром) и результаты, возвращаемые каждым запросом.

Правильно? Но не уверен, зачем нам два кеша для кеширования запросов?

Answer 1

AFAIK
Ответ 01:

Hibernate кэширует загруженные объекты, чтобы избежать нежелательного доступа к базе данных. Самый простой способ избежать контекста персистентности - использовать StatelessSession. Сеанс Hibernate без сохранения состояния не несет ответственности за грязную проверку и, следовательно, соответствует вашему требованию об отсутствии кэша первого уровня (постоянный контекст).

Ответ 02:

1. Вам не нужно включать кэш первого уровня

Ответ 03

1. Если объект загружается дважды в одном и том же сеансе с использованием его идентификатора, Hibernate гарантирует, что один и тот же объект возвращается независимо от того, включен ли кэш второго уровня. Позвольте мне уточнить, что кэш второго уровня НЕ кэширует экземпляры объекта . Он поддерживает сериализованную (не совсем) версию экземпляра. Следующая ссылка дает краткое объяснение структуры кэша второго уровня гибернации.

Извините, но мне не удается понять концепцию "обновление объекта клиента, и оно не отражается в кэше". Надеюсь ссылка прояснит ваш вопрос.

Ответ 04

1. Проблемы с устаревшими данными, извлекаемыми из кэша, возникают, если они настроены неправильно. Данные о состоянии будут извлечены, если время истечения в кеше не произошло. Выселение может быть осуществлено с использованием Session.evict(), однако, скорее всего, у вас может не быть четкого представления о том, какие данные необходимо выселить. Следовательно, кэширование всегда должно быть последним шагом в оптимизации вашего доступа к базе данных. Хороший уровень оптимизации может быть достигнут путем переоценки ассоциаций и планов выборки для отношений сбора, чтобы избежать проблем с выбором N + 1 и в то же время избежать.
   
   EHCache предоставляет read-write стратегии кэширования для данных, которые не обновляются это соответствует транзакции read committed защита. То есть он избегает грязных чтений , но не может помочь против повторных чтений .

Проверьте конфигурацию EHCache здесь

Ответ 05: Кэширование запросов

1. Проверьте эти ссылки для лучшего понимания Session Cache и Query Cache
   A. Кэш сессии
   B. Кэш второго уровня
   C. Кэш запросов

2. Оформить заказ по этой ссылке , которая дает краткое / более простое объяснение структуры кэша запросов.

Надеюсь, это поможет.