Ответ 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 не знает об этом. Также кластеризация без правильной репликации вызовет головную боль. И самая большая проблема - очень часто неправильное кэширование на самом деле замедляет работу приложения (здесь наиболее опасен кеш запросов).