Расширенные знания о кеш-памяти второго уровня Hibernate

Я считаю, что разумное использование кеша 2-го уровня Hibernate улучшит производительность моего приложения, и для этого я начал изучать его из Интернета и из курса Hibernate. Хотя есть довольно хорошие объяснения по кешу 2-го уровня и в основном о том, как он работает, моя цель - точно выяснить, как все работает, начиная с конкретных вопросов, которые я не нашел, поэтому я задам несколько вопросов по кешу Hibernate в целом. и в частности кеш-память 2-го уровня.

Примечания к ответу:

A. Я был бы признателен за ответы на вопросы, даже если некоторые из них кажутся очевидными или несущественными.
B. Если вопрос зависит от поставщика кеша, я бы хотел услышать ответ, который рассказывает об Ehcache
C. Ответы на часть вопросов из-за неуверенности будет приветствоваться

Вопросы:

  1. После настройки кеша 2-го уровня отключается ли кеш-память 1-го уровня? Если нет, то как происходит процесс событий при попытке получить объект, какой уровень кеша попадает первым?

  2. Сохраняет ли кеш запроса текст запроса как HQL или как собственный SQL?

  3. Будет ли кеш 2-го уровня работать одинаково с использованием Hibernate через JPA и Hibernate напрямую?

  4. Я понял, что кеш запросов участвует с кешем 2-го уровня, попадая в кеш 2-го уровня с идентификаторами, которые находятся в кеше запросов. Что, если некоторые из идентификаторов по какой-то причине больше не находятся в кеше 2-го уровня, будут ли снова извлечены все объекты или только часть, которой не существует?

  5. Что касается синхронизации - путем обновления сущности, которая хранится в кэше 2-го уровня, в определенной транзакции - Когда сущность будет обновлена ​​в кеше 2-го уровня, если вообще? Будем признательны за дополнительную информацию о том, как это действие может повлиять как на кеш второго уровня, так и на кеш запросов.


    Спасибо!


java hibernate ehcache second-level-cache query-cache
person Tal Refaeli    schedule 24.08.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

  1. Нет. Кэш первого уровня продолжает использоваться. Единственное отличие состоит в том, что объекты могут поступать из кеша 2-го уровня, а не из базы данных, и что они сохраняются в кеш-память 2-го уровня в дополнение к базе данных.

  2. Не как HQL, поскольку запросы Criteria также можно кэшировать. Я думаю, что используется SQL. Но это не единственное, что нужно кешировать: кешируются и параметры запроса. Однако вам не следует об этом заботиться: кеш кеширует ваши запросы, и все, что он использует, не имеет значения, если выполнение одного и того же запроса дважды попадет в кеш, а выполнение некэшированного запроса - нет.

  3. да.

  4. Только те, которых нет в кеше, AFAIK. Протестируйте его и посмотрите, какие SQL-запросы выполняются.

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

person JB Nizet    schedule 24.08.2013
comment
Относительно ответа № 1 - если я попытаюсь получить объект, который используется как в кеше 1-го, так и 2-го уровня, процесс будет следующим: поиск объекта в кеше 1-го уровня, затем поиск объекта в кеше 2-го уровня, поскольку ни у кого его нет - добавление объекта как в кеш 1-го, так и 2-го уровня. Верно ли мое утверждение? - person Tal Refaeli; 25.08.2013

arrow_upward
0
arrow_downward

Еще несколько деталей:

[4]. Кэш запросов работает вместе с кешем временных меток обновления. Если какой-либо экземпляр типа объекта вставлен / удален / обновлен, все запросы для этого типа объекта будут признаны недействительными. Таким образом, если какая-либо из сущностей исчезла, все запросы для этого типа сущности становятся недействительными, поэтому запрос будет выполнен повторно. Кеш запросов работает таким образом, потому что для Hibernate было бы слишком дорого определять, затрагивается ли конкретный экземпляр каким-либо из запросов, поэтому он использует безопасный, но менее оптимальный подход. Следовательно, кеш запросов может обеспечить повышение производительности только в сценариях, в основном предназначенных только для чтения.

[5]. Обычно кэш второго уровня обновляется в обратном вызове транзакции afterCompletion () Transaction Synchronization.

person Galder Zamarreño    schedule 27.08.2013