Чому відкрита сесія в режимі глибокого сну вважається поганою практикою?

І які альтернативні стратегії ви використовуєте, щоб уникнути LazyLoadExceptions?

Я розумію, що відкрита сесія має на увазі проблеми з:

• Багатошарові програми, що працюють у різних jvm-кодах
• Операції здійснюються лише в кінці, і, швидше за все, ви хотіли б отримати результати раніше.

Але, якщо ви знаєте, що ваша програма працює на одному vm, чому б не полегшити свій біль, використовуючи відкриту сесію в стратегії перегляду?

Оскільки надсилання можливо неініціалізованих проксі, особливо колекцій, у шар перегляду та спричинення завантаження зі сплячого режиму звідти може викликати занепокоєння як з точки зору продуктивності, так і з розуміння.

Розуміння :

Використання OSIV "забруднює" шар перегляду занепокоєнням, пов'язаним із рівнем доступу до даних.

Шар перегляду не готується до обробки, HibernateExceptionщо може статися при ледачому завантаженні, але, мабуть, рівень доступу до даних є.

Продуктивність :

OSIV, як правило, перетягує належне завантаження під килим - ви, як правило, не помічаєте, що ваші колекції чи об'єкти ліниво ініціалізовані (можливо, N + 1). Більше зручності, менше контролю.

Оновлення: див . Антипаттерн OpenSessionInView для більшого обговорення цієї теми. Автор перелічує три важливі моменти:

1. кожна лінива ініціалізація отримає вам запит, тобто кожному суб'єкту знадобиться N + 1 запитів, де N - кількість лінивих асоціацій. Якщо на екрані представлені табличні дані, читання журналу сплячки - це великий натяк на те, що ви не робите так, як слід
2. це повністю перемагає шарувату архітектуру, оскільки ви цокотіть свої нігті з БД в шарі презентації. Це концептуальна проблема, тому я міг би жити з цим, але є наслідком
3. нарешті, але не менш важливо, якщо виняток виникає під час отримання сеансу, це станеться під час написання сторінки: ви не можете представити користувачеві чисту сторінку помилок, і єдине, що ви можете зробити, це написати повідомлення про помилку в тілі

Для більш детального опису ви можете прочитати мою статтю " Відкрита сесія" у "Перегляд протизразка" . В іншому випадку, ось короткий опис того, чому не слід використовувати Open Session In View.

Відкрита сесія в режимі перегляду погано підходить до отримання даних. Замість того, щоб дозволити бізнес-шару вирішувати, як найкраще отримати всі асоціації, необхідні шару «Перегляд», він змушує Контекст стійкості залишатися відкритим, щоб шар Перегляд може спровокувати ініціалізацію проксі.

• OpenSessionInViewFilterВикликає openSessionметод базового активу SessionFactoryі отримує новий Session.
• SessionПов'язаний з TransactionSynchronizationManager.
• OpenSessionInViewFilterНазиває doFilterв якості javax.servlet.FilterChainпосилання об'єкта і запит додатково обробляється
• DispatcherServletНазивається, і він направляє запит HTTP , щоб лежачий в основі PostController.
• У PostControllerдзвінки на , PostServiceщоб отримати список Postсутностей.
• PostServiceВідкриває нову транзакцію, і HibernateTransactionManagerповторно той же , Sessionщо був відкритий OpenSessionInViewFilter.
• PostDAOОтримує список Postосіб без ініціалізації будь ледачою асоціації.
• PostServiceЗдійснює основну угоду, але Sessionне закритий , так як він був відкритий зовні.
• У DispatcherServletзапуску рендеринга інтерфейсу, який, в свою чергу, переходить ледачі асоціації і викликає їх ініціалізації.
• Can OpenSessionInViewFilterможе закрити Session, і базове з'єднання бази даних також вивільнено.

На перший погляд, це може не виглядати як жахлива річ, але, коли ви переглядаєте це з точки зору бази даних, ряд недоліків починає ставати більш очевидним.

Сервісний рівень відкривається та закриває транзакцію бази даних, але після цього явної транзакції не відбувається. З цієї причини кожна додаткова заява, видана на етапі візуалізації користувальницького інтерфейсу, виконується в режимі автоматичної фіксації. Функція автоматичного фіксації чинить тиск на сервер бази даних, оскільки кожне твердження повинно передати журнал транзакцій на диск, тому спричиняючи багато трафіку вводу / виводу на стороні бази даних. Однією з оптимізацій було б позначити Connectionяк лише для читання, що дозволить серверу баз даних уникати запису в журнал транзакцій.

Більше проблем не існує, оскільки заяви створюються як службовим рівнем, так і процесом надання інтерфейсу користувача. Для написання тестів на інтеграцію, що підтверджують кількість генерованих висловлювань, потрібно пройти всі шари (веб, сервіс, DAO), при цьому додаток буде розміщено у веб-контейнері. Навіть при використанні бази даних в пам'яті (наприклад, HSQLDB) та легкого веб-сервера (наприклад, Jetty), ці інтеграційні тести виконуватимуться повільніше, ніж якщо б шари були розділені і тести інтеграції заднім числом використовували базу даних, тоді як фронтальні тести інтеграції взагалі глузували з сервісного рівня.

Шар інтерфейсу обмежений навігаційними асоціаціями, які, в свою чергу, можуть викликати проблеми запитів N + 1. Незважаючи на те, що Hibernate пропонує @BatchSizeпакетні асоціації для отримання пакетів і FetchMode.SUBSELECTдля вирішення цього сценарію, примітки впливають на план вибору за замовчуванням, тому вони застосовуються до кожного випадку використання бізнесу. З цієї причини запит рівня доступу до даних набагато підходить, оскільки він може бути налаштований під поточні вимоги використання даних щодо поточного використання.

І останнє, але не менш важливе, підключення до бази даних може відбуватися протягом усієї фази візуалізації інтерфейсу (залежно від режиму випуску з'єднання), що збільшує час оренди з'єднання та обмежує загальну пропускну здатність транзакцій через перевантаженість пулу підключення до бази даних. Чим більше з'єднання проведено, тим більше інших одночасних запитів буде чекати, щоб отримати з'єднання з пулу.

Таким чином, або ви тримаєте з'єднання занадто довго, або ви отримуєте / випускаєте кілька з'єднань для одного HTTP-запиту, тому тиснуть на базовий пул з'єднань і обмежуючи масштабованість.

Весняний черевик

На жаль, Open Session in View увімкнено у Spring Boot за замовчуванням .

Отже, переконайтеся, що у application.propertiesфайлі конфігурації є такий запис:

spring.jpa.open-in-view=false

Це відключить OSIV, щоб ви могли правильно впоратисяLazyInitializationException .

• транзакції можуть здійснюватися на рівні обслуговування - транзакції не пов'язані з OSIV. Це те, Sessionщо залишається відкритим, а не транзакція.

• якщо шари вашої програми поширюються на декілька машин, ви майже не можете використовувати OSIV - вам доведеться ініціалізувати все необхідне, перш ніж надсилати об’єкт по дроту.

• OSIV - це приємний і прозорий (тобто ніхто з вашого коду не знає, що це відбувається) спосіб використовувати переваги продуктивності від ледачого завантаження

Я б не сказав, що відкрита сесія в перегляді вважається поганою практикою; що справляє таке враження?

Open-Session-In-View - це простий підхід до обробки сеансів роботи зі сплячим режимом. Оскільки це просто, іноді спрощено. Якщо вам потрібен тонкий контроль над транзакціями, наприклад, кілька запитів у запиті, Open-Session-In-View - це не завжди хороший підхід.

Як зазначали інші, існують певні компроміси в OSIV - ви набагато більше схильні до проблеми N + 1, оскільки ви менше шансів усвідомити, які транзакції ви починаєте. У той же час це означає, що вам не потрібно змінювати рівень обслуговування, щоб адаптуватися до незначних змін у вашому представленні даних.

Якщо ви використовуєте контейнер Інверсії управління (IoC), такий як Spring, вам, можливо, захочеться ознайомитись із визначенням квасолі . По суті, я кажу Spring, щоб він дав мені сплячий Sessionоб'єкт, життєвий цикл якого охоплює весь запит (тобто він створюється та знищується на початку та в кінці запиту HTTP). Мені не потрібно хвилюватися з приводу LazyLoadExceptionзакриття сесії, оскільки контейнер IoC управляє цим для мене.

Як уже згадувалося, вам доведеться думати про проблеми з продуктивністю N + 1 SELECT. Ви завжди можете налаштувати свою сплячу особу після цього, щоб не хочуть приєднуватися до завантаження в місцях, де продуктивність є проблемою.

Рішення для збору квасолі не є специфічним для весни. Я знаю, що PicoContainer пропонує ті ж можливості, і я впевнений, що інші зрілі контейнери IoC пропонують щось подібне.

На мій власний досвід, OSIV не такий вже й поганий. Єдине домовленість, яку я зробив, - це використання двох різних транзакцій: - перша, відкрита в "сервісному шарі", де я маю "бізнес-логіку", - друга відкрита перед відображенням перегляду

Я щойно написав повідомлення про деякі вказівки щодо використання відкритого сеансу для перегляду в своєму блозі. Перевірте це, якщо цікавитесь.

http://heapdump.wordpress.com/2010/04/04/should-i-use-open-session-in-view/

Я проти іржавого режиму .. але я думаю, що за один сеанс сплячки можливо зробити кілька транзакцій. Тож межі транзакцій не повинні бути такими ж, як події початку / зупинки сесії.

OSIV, imo, в першу чергу корисний, оскільки ми можемо уникати написання коду для запуску "контексту постійності" (він же сеанс) кожного разу, коли запит потребує доступу до БД.

У вашому сервісному шарі, ймовірно, вам потрібно буде здійснювати дзвінки до методів, які мають різні потреби в транзакціях, таких як "Необхідно, Нове Потрібно тощо". Єдине, що потрібно цим методам, це те, що хтось (тобто фільтра OSIV) запустив контекст постійності, так що єдине, про що вони повинні турбуватися, - це "дайте мені сплячий сеанс для цього потоку. Мені потрібно зробити кілька БД ".

Це не допоможе занадто багато, але ви можете перевірити мою тему тут: * Hibernate Cache1 OutOfMemory з OpenSessionInView

У мене є деякі проблеми OutOfMemory через OpenSessionInView та багато завантажених організацій, оскільки вони залишаються в рівні кешу Hibernate1 і не збирають сміття (я завантажую багато об'єктів з 500 елементами на сторінку, але всі об'єкти залишаються в кеші)