Подтвердить что ты не робот

Кеширование с Hibernate + Spring - некоторые вопросы

Я работаю над разработкой веб-приложения для Spring 3 и Hibernate 3.6. В данный момент я пытаюсь понять, как работает Caching with Spring и Hibernate. Я нашел несколько источников о кэшировании в Hibernate, а некоторые о Spring, и сейчас я пытаюсь собрать свою информацию. У меня все еще есть вопросы к обеим платформам, и я буду рад, если кто-нибудь ответит на них или скажет, верны ли приведенные здесь факты.

В большинстве случаев коротких ответов (да/нет) будет достаточно. Я думаю, что этот список может быть полезен и для других, которые хотят понять, как работает кэширование в Spring и Hibernate.

General

1) Hibernate поддерживает следующие кэши: кэш 1-го уровня, кэш 2-го уровня, кэш запросов

2) Сам Spring поддерживает следующие возможности кэширования: просто метод кэширования

1st Level Cache

3) Кэш 1-го уровня является частью КАЖДОГО приложения Hibernate.

4) Кэш 1-го уровня создан для КАЖДОГО hibernate-сеанса.

5) Что сохраняется в кэше 1-го уровня? Объекты или просто значения их свойств? запросы и их результаты?

2nd Level Cache

6) Я узнал: кэш 2-го уровня используется ОДИН РАЗ для каждого приложения. разве это не ложь? Разве он не используется ОДИН РАЗ в SessionFactory? и: несколько sessionfactorys = возможно несколько кэшей 2-го уровня?

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

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

9) при обновлении значений одного объекта в кеше 2-го уровня возможно ли обновление значений объектов, связанных с ним, также в кеше?

10) когда значения объекта меняются, как я могу обновить кэш 2-го уровня? промывать? можно просто обновить часть кэша или нужно обновить весь кеш?

11) где кэш 2-го уровня имеет смысл, а где нет?

12) Режим кэширования: обеспечивает ли каждый режим кэширования свою стратегию кэширования? например, с режимом кэширования "только для чтения" синхронизация базы данных и кеша не требуется? другие режимы кэша обеспечивают синхронизацию? Я думал, что синхронизация должна быть сделана самим разработчиком?

Query Cache

13) В чем разница между кешем запросов и кешем 2-го уровня? на мой взгляд: в Query Cache сохраняются наборы результатов, но не с их значениями, а только с их идентификаторами. когда запрос используется снова, а набор результатов по-прежнему "правильный", значения, принадлежащие идентификаторам, запрашиваются из кэша 2-го уровня

14) Для кеша запросов ДОЛЖЕН использоваться кэш 2-го уровня?

15) где кэш запросов имеет смысл, а где нет?

Spring

16) Предоставляет ли Spring больше возможностей для кэширования, чем для кэширования методов?

17) метод кэширования не связан с кэшированием в спящем режиме

18) но: для кеширования метода необходим 2-й уровень, такой как Ehcache (который также может использоваться hibernate)

19) можно ли использовать метод кэширования без запросов к базе данных?

Getting mixed up

20) Если я использую ehcache для спящего режима в качестве кэша 2-го уровня и Ehcache для весны для кеширования методов, могу ли я использовать тот же экземпляр Ehcache? есть ли вероятность, что что-то запуталось?

21) при использовании кэша 1-го уровня и кэша 2-го уровня они могут быть перепутаны? при запросе к базе данных откуда берется результат, кеш 1-го или 2-го уровня? работает кеш 1-го уровня с кешем 2-го уровня?

22) что-нибудь еще, что может быть перепутано с использованием упомянутых кешей? :-)

Спасибо за ответ, независимо от того, какой вопрос! :-)

4b9b3361

Ответ 1

  Hibernate поддерживает следующие кэши: кэш 1-го уровня, кэш 2-го уровня, кэш запросов

Да.

Сам Spring поддерживает следующие возможности кеширования: просто кеширование методов

В Spring 3.1 представлена новая абстракция кэширования, основанная на аннотациях вокруг методов, да.

Кэш 1-го уровня является частью КАЖДОГО приложения Hibernate.

Да.

Кэш 1-го уровня создан для КАЖДОГО hibernate-сеанса.

Да, хотя вы можете очистить его вручную в любой момент.

Что сохраняется в кэше 1-го уровня? Объекты или просто значения их свойств? запросы и их результаты?

Это карта всех объектов, выбранных в течение жизни сеанса. Если вы загружаете один и тот же объект по идентификатору во второй раз, он будет загружен из L1.

Я выяснил: кэш 2-го уровня используется ОДИН РАЗ для каждого приложения. разве это не ложь? Разве это не используется ОДИН РАЗ в каждом сеансе? и: несколько sessionfactorys = возможно несколько кэшей 2-го уровня?

Вы правы, как правило, существует только одна фабрика сеансов для каждого приложения (базы данных), поэтому существует ярлык.

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

То же самое, что и в L1, но они живут дольше. L2 обычно поддерживается промышленным кешем, в то время как L1 - просто карта (она даже не должна быть поточно-ориентированной). Он хранит полные сущности, включая лениво загруженные отношения.

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

Вы не управляете L2 вручную, это происходит автоматически.

при обновлении значений одного объекта в кеше 2-го уровня возможно ли обновление значений объектов, связанных с ним в кеше тоже?

См. выше.

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

Смотрите выше - Hibernate выяснит это для вас. Вы никогда не взаимодействуете с L2 напрямую.

где кэш 2-го уровня имеет смысл, а где нет?

Мера. В приложениях, которые читают много данных по первичному ключу и коэффициенту чтения-записи очень высок, L2 оказывает значительное влияние на вашу производительность.

Режим кэширования: каждый режим кэширования обеспечивает свою стратегию кэширования? например, с режимом кэширования "только для чтения" синхронизация базы данных и кеша не требуется? другие режимы кэша обеспечивают синхронизацию? Я думал, что синхронизация должна быть сделана самим разработчиком?

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

В чем разница между кешем запросов и кешем 2-го уровня? на мой взгляд: в Query Cache сохраняются наборы результатов, но не с их значениями, а только с их идентификаторами. когда запрос используется снова и набор результатов по-прежнему "правильный", значения, принадлежащие идентификаторам, запрашиваются из кэша 2-го уровня.

Точно, но это очень широкая тема. Особенно набор результатов по-прежнему является "правильной" частью.

Для кеша запросов ДОЛЖЕН использоваться кэш 2-го уровня?

Да, без кеша L2 кеш запросов не имеет смысла и значительно замедлит работу приложения.

где смысл кеша запросов, а где нет?

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

Предоставляет ли Spring больше возможностей кэширования, чем кэширование методов?

Нет, Spring более или менее просто клей для вашего собственного кода.

Кэширование метода не связано с кэшированием в спящем режиме.

Spring не связана с Hibernate, так что...

но: для кэширования методов необходим 2-й уровень, например, ehcache (который также может использоваться hibernate)

L2 - это концепция Hibernate. Если вы хотите кэшировать методы, вам нужен некоторый базовый кеш. Пусть это будет EhCache, неважно. конечно это должно быть потокобезопасным.

можно ли использовать метод кэширования без запросов к базе данных?

Spring не имеет ничего общего с Hibernate. Вы можете кэшировать вычисления, которые не имеют ничего общего с базой данных.

если использовать ehcache для hibernate в качестве кэша 2-го уровня и ehcache для spring для кэширования методов, могу ли я использовать один и тот же экземпляр ehcache? есть ли вероятность, что что-то запуталось?

Вы можете использовать ту же конфигурацию CacheManager и кеша, что и в Hibernate, чтобы упростить развертывание. Пока имена кэша не перекрываются, они полностью независимы, даже если работают в одном и том же менеджере.

при использовании кеша 1-го уровня и кеша 2-го уровня они могут перепутаться? при запросе к базе данных откуда берется результат, кеш 1-го или 2-го уровня? работает кеш 1-го уровня с кешем 2-го уровня?

Они просто работают, пока какая-то абстракция не просочится :-). Когда вы выполняете запрос по первичному ключу, сначала проверяется L1 (он быстрее), а затем L2.

что-нибудь еще, что может быть перепутано с использованием упомянутых кешей? :-)

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

Ответ 2

В отношении Spring и кеша второго уровня есть классный проект с открытым исходным кодом, который может hel Spring работать с кешем 2L:

Например: http://code.google.com/p/ehcache-spring-annotations/

Мы используем его в производственной среде, и это делает нашу жизнь намного проще.