¿Qué es esto spring.jpa.open-in-view=true propiedad en Spring Boot?

Te recomendamos que revises esta respuesta en un entorno controlado antes de enviarlo a producción, un saludo.

Solución:

El antipatrón OSIV

En lugar de dejar que la capa empresarial decida cómo es mejor obtener todas las asociaciones que necesita la capa de vista, OSIV (Open Session in View) obliga al contexto de persistencia a permanecer abierto para que la capa de vista pueda desencadenar la inicialización del proxy, como se ilustra. por el siguiente diagrama.

• los OpenSessionInViewFilter llama al openSession método del subyacente SessionFactory y obtiene una nueva Session.
• los Session está ligado a la TransactionSynchronizationManager.
• los OpenSessionInViewFilter llama al doFilter de El javax.servlet.FilterChain referencia de objeto y la solicitud se procesa más
• los DispatcherServlet se llama, y ​​enruta la solicitud HTTP a la subyacente PostController.
• los PostController llama al PostService para obtener una lista de Post entidades.
• los PostService abre una nueva transacción, y el HibernateTransactionManager reutiliza lo mismo Session que fue inaugurado por el OpenSessionInViewFilter.
• los PostDAO obtiene la lista de Post entidades sin inicializar ninguna asociación perezosa.
• los PostService compromete la transacción subyacente, pero el Session no está cerrado porque fue abierto por fuera.
• los DispatcherServlet comienza a representar la interfaz de usuario, que, a su vez, navega por las asociaciones perezosas y activa su inicialización.
• los OpenSessionInViewFilter puede cerrar el Sessiony también se libera la conexión de la base de datos subyacente.

A primera vista, esto puede no parecer algo terrible, pero, una vez que lo ve desde la perspectiva de la base de datos, una serie de fallas comienzan a ser más obvias.

La capa de servicio abre y cierra una transacción de la base de datos, pero luego no hay una transacción explícita en curso. Por esta razón, cada instrucción adicional emitida desde la fase de representación de la interfaz de usuario se ejecuta en modo de confirmación automática. La confirmación automática ejerce presión sobre el servidor de la base de datos porque cada transacción emite una confirmación al final, lo que puede desencadenar un vaciado del registro de transacciones en el disco. Una optimización sería marcar el Connection como de solo lectura, lo que permitiría que el servidor de la base de datos evite escribir en el registro de transacciones.

Ya no hay separación de preocupaciones porque las declaraciones son generadas tanto por la capa de servicio como por el proceso de representación de la interfaz de usuario. Escribir pruebas de integración que afirmen la cantidad de declaraciones que se generan requiere pasar por todas las capas (web, servicio, DAO) mientras se implementa la aplicación en un contenedor web. Incluso cuando se usa una base de datos en memoria (por ejemplo, HSQLDB) y un servidor web liviano (por ejemplo, Jetty), estas pruebas de integración serán más lentas de ejecutar que si las capas estuvieran separadas y las pruebas de integración de back-end usaran la base de datos, mientras que el frente Las pruebas de integración final se burlaban de la capa de servicio por completo.

La capa de la interfaz de usuario se limita a las asociaciones de navegación que, a su vez, pueden desencadenar problemas de consulta N+1. Aunque Hibernate ofrece @BatchSize para buscar asociaciones en lotes, y FetchMode.SUBSELECT Para hacer frente a este escenario, las anotaciones afectan el plan de recuperación predeterminado, por lo que se aplican a cada caso de uso comercial. Por esta razón, una consulta de capa de acceso a datos es mucho más adecuada porque se puede adaptar a los requisitos de obtención de datos del caso de uso actual.

Por último, pero no menos importante, la conexión de la base de datos se mantiene durante la fase de representación de la interfaz de usuario, lo que aumenta el tiempo de arrendamiento de la conexión y limita el rendimiento general de la transacción debido a la congestión en el grupo de conexiones de la base de datos. Cuanto más se mantenga la conexión, más solicitudes simultáneas esperarán para obtener una conexión del grupo.

Arranque de primavera y OSIV

Desafortunadamente, OSIV (Open Session in View) está habilitado de forma predeterminada en Spring Boot, y OSIV es realmente una mala idea desde una perspectiva de rendimiento y escalabilidad.

Por lo tanto, asegúrese de que en el application.properties archivo de configuración, tiene la siguiente entrada:

spring.jpa.open-in-view=false

Esto deshabilitará OSIV para que pueda manejar el LazyInitializationException la direccion correcta.

A partir de la versión 2.0, Spring Boot emite una advertencia cuando OSIV está habilitado de forma predeterminada, por lo que puede descubrir este problema mucho antes de que afecte a un sistema de producción.

Esta propiedad registrará un OpenEntityManagerInViewInterceptorque registra un EntityManager al hilo actual, por lo que tendrá el mismo EntityManager hasta que finalice la solicitud web. No tiene nada que ver con un Hibernate. SessionFactory etc

Valoraciones y reseñas

Recuerda que tienes el privilegio valorar este artículo si te fue preciso.

---

---

Utiliza Nuestro Buscador