Які кеші першого та другого рівнів в режимі сплячки?
Відповіді:
1.1) Кеш першого рівня
Кеш першого рівня завжди асоціюється з об'єктом сесії . Hibernate використовує цей кеш за замовчуванням. Тут він обробляє одну транзакцію за іншою, означає багато разів обробляти одну транзакцію. В основному це зменшує кількість запитів SQL, які потрібно генерувати в межах певної транзакції. Тобто замість оновлення після кожної модифікації, здійсненої в транзакції, вона оновлює транзакцію лише в кінці транзакції.
1.2) Кеш другого рівня
Кеш другого рівня завжди асоціюється з об'єктом "Фабрика сеансів" . Під час виконання транзакцій між ними він завантажує об'єкти на рівні "Фабрика сеансів", щоб ці об'єкти були доступні для всієї програми, не пов'язаної з одним користувачем. Оскільки об'єкти вже завантажені в кеш-пам'ять, кожного разу, коли об’єкт повертається запитом, в цей час не потрібно йти на транзакцію з базою даних. Таким чином працює кеш другого рівня. Тут ми також можемо використовувати кеш рівня рівня запитів.
Цитується з: http://javabeat.net/introduction-to-hibernate-caching/
У блозі Streamline Logic є досить хороше пояснення кешування першого рівня .
В основному кешування першого рівня відбувається на основі сеансу за кожний сеанс, коли кешування другого рівня може бути спільним для декількох сеансів.
Ось кілька основних пояснень кеш-пам'яті в сплячому режимі ...
Кеш першого рівня асоціюється з об'єктом "сеанс". Обсяг об’єктів кеша - це сеанс. Після закриття сеансу кешовані об’єкти назавжди зникнуть. Кеш першого рівня ввімкнено за замовчуванням, і ви не можете його відключити. Коли ми запитуємо сутність вперше, вона витягується з бази даних і зберігається в кеші першого рівня, пов’язаному з сплячим сеансом. Якщо ми знову запитаємо той самий об’єкт з тим самим об’єктом сеансу, він буде завантажений з кешу, і запит sql не буде виконаний. Завантажену сутність можна видалити з сеансу за допомогою evict()методу. Наступне завантаження цього об'єкта знову зробить виклик бази даних, якщо його було видалено evict()методом. Весь кеш сеансу можна видалити за допомогою clear()методу. Це видалить усі об'єкти, що зберігаються в кеші.
Кеш другого рівня є окрім кешу першого рівня, який доступний для використання в усьому світі в заводській області сеансу. Кеш другого рівня створюється в заводській області сеансу і доступний для використання у всіх сесіях, створених за допомогою конкретної фабрики сеансів. Це також означає, що коли заводська сесія закрита, усі кеші, пов'язані з нею, гинуть, а кеш-менеджер також закривається. Щоразу, коли сеанс сплячого режиму намагається завантажити суб'єкт, найперше воно шукає кешовану копію сутності в кеші першого рівня (пов'язане з конкретним сеансом сплячого режиму). Якщо кешована копія сутності присутня в кеші першого рівня, вона повертається в результаті методу завантаження. Якщо в кеші першого рівня немає кешованої сутності, то кеш-пам'ять другого рівня шукається. Якщо кеш-пам'ять другого рівня має кешоване об'єкт, він повертається в результаті методу навантаження. Але, перед поверненням сутності він також зберігається в кеші першого рівня, щоб наступний виклик для методу завантаження для сутності повернув сутність із кешу першого рівня, і не потрібно буде знову переходити до кешу другого рівня. Якщо сутність не знайдена в кеші першого рівня та кешу другого рівня, тоді виконується запит до бази даних і об'єкт зберігається в обох рівнях кешу, перш ніж повернутися як відповідьload() метод.
Це дуже поширене питання, тому ця відповідь заснована на цій статті, яку я написав у своєму блозі.
Кеш першого рівня
Зимова сплячка намагається відкласти контекст Наполегливості, що розгорається, до останнього можливого моменту. Як я пояснив у цій статті , ця стратегія традиційно називається транзакційним списанням.
Списання більше пов'язане зі змиванням у сплячому режимі, а не з будь-якою логічною чи фізичною транзакцією. Під час транзакції промивання може виникати кілька разів.
Розмиті зміни видно лише для поточної транзакції бази даних. Доти, доки не буде здійснена поточна транзакція, інші паралельні транзакції не помітні.
Завдяки кешу першого рівня Hibernate може зробити кілька оптимізацій:
Кеш другого рівня
Правильне рішення кешування повинно охоплювати декілька сеансів сплячого режиму, і тому Hibernate також підтримує додатковий кеш другого рівня.
Кеш другого рівня пов'язаний з життєвим циклом SessionFactory, тому він руйнується лише тоді, коли SessionFactoryзакритий (зазвичай, коли програма закривається). Кеш другого рівня орієнтований насамперед на сутність, хоча він також підтримує необов'язкове рішення кешування запитів.
Більш детально ознайомтеся з цією статтею .
за замовчуванням NHibernate використовує кешування першого рівня, що базується на об'єкті сеансу. але якщо ви працюєте в середовищі з декількома серверами, то кеш першого рівня може не дуже масштабуватися разом із деякими проблемами продуктивності. це трапляється через те, що йому доводиться робити дуже часті поїздки до бази даних, оскільки дані поширюються на декілька серверів. Іншими словами, NHibernate забезпечує базовий, не дуже складний кеш L1 в процесі роботи поза коробкою. Однак він не надає функцій, за якими рішення кешування повинно мати помітний вплив на продуктивність програми.
тож питаннями всіх цих проблем є використання кешу L2, який пов'язаний з фабричними об'єктами сеансу. це скорочує трудомісткі поїздки в базу даних, тому в кінцевому підсумку збільшує час відгуку програми.
Кеш першого рівня
Об'єкт сесії містить дані кешу першого рівня. Він включений за замовчуванням. Дані кеша першого рівня не будуть доступні для всієї програми. Додаток може використовувати багато об'єктів сеансу.
Кеш другого рівня
Об'єкт SessionFactory містить дані кешу другого рівня. Дані, що зберігаються в кеші другого рівня, будуть доступні для всієї програми. Але нам це потрібно чітко включити.
У кеш-пам'яті другого рівня доменні файли hbm можуть бути ключовими змінними та значеннями false. Наприклад, у цьому доменному класі деяка тривалість у добу залишається постійною як універсальна істина. Таким чином, це може бути позначено як непорушне протягом усього застосування.