[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-hibernate-chto-takoe-kesh-vtorogo-urovnya-l2-cache":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":19,"progress":20,"seo":21},758,"chto-takoe-kesh-vtorogo-urovnya-l2-cache",19,"hibernate","Hibernate","🐻","Что такое кэш второго уровня (L2 Cache)?","Кэш второго уровня (L2 Cache) — опциональный кэш, разделяемый между всеми Session в рамках одного SessionFactory. В отличие от L1, хранит данные между транзакциями.\n\n### Архитектура кэширования\n\n```\nSession 1 → L1 Cache ─┐\nSession 2 → L1 Cache ──┤──→ L2 Cache ──→ БД\nSession 3 → L1 Cache ─┘\n```\n\nПоиск сущности: L1 Cache → L2 Cache → БД\n\n### Настройка L2 Cache с Ehcache\n\n```xml\n\u003C!-- pom.xml -->\n\u003Cdependency>\n    \u003CgroupId>org.hibernate.orm\u003C\u002FgroupId>\n    \u003CartifactId>hibernate-jcache\u003C\u002FartifactId>\n\u003C\u002Fdependency>\n\u003Cdependency>\n    \u003CgroupId>org.ehcache\u003C\u002FgroupId>\n    \u003CartifactId>ehcache\u003C\u002FartifactId>\n\u003C\u002Fdependency>\n```\n\n```properties\n# application.properties\nspring.jpa.properties.hibernate.cache.use_second_level_cache=true\nspring.jpa.properties.hibernate.cache.region.factory_class=jcache\nspring.jpa.properties.javax.cache.provider=org.ehcache.jsr107.EhcacheCachingProvider\n```\n\n```java\n@Entity\n@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)\npublic class Department {\n    @Id\n    private Long id;\n    private String name;\n}\n```\n\n### Стратегии конкурентного доступа\n\n| Стратегия | Описание | Применение |\n|-----------|----------|------------|\n| READ_ONLY | Только чтение, данные не меняются | Справочники, словари |\n| NONSTRICT_READ_WRITE | Чтение\u002Fзапись без строгой согласованности | Редко обновляемые данные |\n| READ_WRITE | Чтение\u002Fзапись с мягкими блокировками | Часто читаемые, редко обновляемые |\n| TRANSACTIONAL | Полная транзакционная согласованность (JTA) | Критичные данные |\n\n### Важное\n\n- L2 Cache — опциональный, разделяемый между всеми Session\n- Кэшируются данные (не объекты) — при чтении из L2 создаётся новый Java-объект\n- L2 Cache эффективен для часто читаемых, редко обновляемых данных (справочники, каталоги)\n- Провайдеры: Ehcache, Caffeine (через JCache), Infinispan, Hazelcast\n\n### Частые ошибки\n\n- Кэшировать часто обновляемые данные — L2 Cache добавит overhead на инвалидацию без выигрыша\n- Не кэшировать коллекции — даже если сущность в кэше, её коллекции нужно кэшировать отдельно (`@Cache` на коллекции)\n- Забыть про инвалидацию при прямом SQL — native queries и bulk operations обходят L2 Cache\n- L2 Cache в кластере без распределённого кэша — каждый узел имеет свою копию, данные расходятся\n\n### Как используется в 2026\n\n- L2 Cache используется для справочных данных (страны, категории, настройки)\n- Для distributed кэширования — Redis\u002FHazelcast вместо локального Ehcache\n- Тренд: кэширование на уровне сервиса (Spring Cache + Redis) вместо L2 Cache Hibernate\n- L2 Cache остаётся полезным для монолитов; в микросервисах — Spring Cache предпочтительнее\n\n> **На собеседовании:** отличайте L1 от L2: L1 — обязательный, привязан к Session\u002Fтранзакции; L2 — опциональный, общий для всех Session. Упомяните стратегии конкурентного доступа (READ_ONLY для справочников). Частый подвох — «а что будет при native SQL?» — L2 Cache не инвалидируется автоматически.","","junior",[15,16,17,7,18],"persistence-context","l1-cache","jpa","caching",[],null,{"title":22,"description":23,"ogTitle":24,"ogDescription":25,"keywords":26,"schemaAnswer":34,"featuredSnippetReady":35},"Кэш первого уровня (L1 Cache) в Hibernate — Gymterview","L1 Cache = Persistence Context = Session. Обязательный кэш в рамках транзакции: identity guarantee, Dirty Checking, write-behind. Очистка через clear().","L1 Cache в Hibernate: Persistence Context и identity guarantee — Gymterview","L1 Cache — обязательный кэш Hibernate, привязанный к Session. Гарантия identity, Dirty Checking, write-behind. Проблема OOM при batch.",[27,28,29,30,31,32,8,33],"L1 Cache","кэш первого уровня","Persistence Context","Session","Dirty Checking","identity","JPA","L1 Cache (кэш первого уровня) — Persistence Context, привязанный к Session\u002FEntityManager. Обязательный кэш, нельзя отключить. Живёт в рамках одной транзакции. Гарантирует identity (один ID → один объект), обеспечивает Dirty Checking и write-behind (SQL откладывается до flush). При batch-обработке нужен clear() для предотвращения OutOfMemoryError.",true]