java - 为什么 Hibernate Open Session in View 被认为是不好的做法？

Question

您使用什么样的替代策略来避免 LazyLoadExceptions？

我确实了解 View 中的开放式 session 存在以下问题:

在不同 jvm 中运行的分层应用程序

事务只在最后提交，而且很可能你会喜欢之前的结果。

但是，如果您知道您的应用程序运行在单个 vm 上，为什么不通过在 View 中使用开放 session 策略来减轻您的痛苦呢？

Answer 1

在 View 中打开 session 采用了一种糟糕的方法来获取数据。它不是让业务层决定如何最好地获取 View 层所需的所有关联，而是强制持久化上下文保持打开状态，以便 View 层可以触发代理初始化。

OpenSessionInViewFilter调用 openSession底层方法SessionFactory并获得新的 Session .

Session绑定(bind)到 TransactionSynchronizationManager .

OpenSessionInViewFilter调用 doFilter的javax.servlet.FilterChain对象引用和请求被进一步处理

DispatcherServlet 被调用，它将 HTTP 请求路由到底层 PostController .

PostController调用 PostService获取 Post 的列表实体。

PostService打开一个新的交易，和HibernateTransactionManager重复使用相同的 Session由 OpenSessionInViewFilter 打开的.

PostDAO获取 Post 的列表实体而不初始化任何惰性关联。

PostService提交基础事务，但 Session没有关闭，因为它是从外部打开的。

DispatcherServlet开始渲染 UI，而 UI 反过来导航惰性关联并触发它们的初始化。

OpenSessionInViewFilter可以关闭Session ，并且底层数据库连接也被释放。

乍一看，这似乎不是一件可怕的事情，但是，一旦从数据库的角度来看，一系列缺陷就开始变得更加明显。
服务层打开和关闭一个数据库事务，但之后没有显式事务在进行。出于这个原因，从 UI 呈现阶段发出的每个附加语句都在自动提交模式下执行。自动提交给数据库服务器带来压力，因为每个语句都必须将事务日志刷新到磁盘，从而导致数据库端的大量 I/O 流量。一种优化是标记 Connection作为只读，这将允许数据库服务器避免写入事务日志。
不再有关注点分离，因为语句是由服务层和 UI 渲染过程生成的。编写集成测试 assert the number of statements being generated需要遍历所有层(Web、服务、DAO)，同时将应用程序部署在 Web 容器上。即使在使用内存数据库(例如 HSQLDB)和轻量级 Web 服务器(例如 Jetty)时，这些集成测试的执行速度也会比层分离并且后端集成测试使用数据库时要慢，而前端集成测试完全模拟了服务层。
UI 层仅限于导航关联，这反过来又会触发 N+1 查询问题。尽管 Hibernate 提供 @BatchSize 用于批量获取关联，以及 FetchMode.SUBSELECT 为了应对这种情况，注释会影响默认获取计划，因此它们被应用于每个业务用例。出于这个原因，数据访问层查询更合适，因为它可以针对当前用例数据获取需求进行定制。
最后但并非最不重要的是，数据库连接可以在整个 UI 呈现阶段(取决于您的连接 Release模式)保持，这会增加连接租用时间并由于数据库连接池拥塞而限制整体事务吞吐量。保持的连接越多，其他并发请求将等待从池中获取连接的次数就越多。
因此，要么您将连接保持的时间过长，要么为单个 HTTP 请求获取/释放多个连接，从而给底层连接池带来压力并限制可扩展性。
Spring 靴
不幸的是， Open Session in View is enabled by default in Spring Boot .
因此，请确保在 application.properties 中配置文件，你有以下条目:

spring.jpa.open-in-view=false

这将禁用 OSIV，以便您可以处理 LazyInitializationException正确的方法，通过获取所有需要的关联，而 EntityManager是开放的。