扩展(或长)会话(或每会话会话)是一个会话,可以超出事务的持续时间,而不是事务范围的会话(或每个请求的会话).这不一定是反模式,这是实现长对话(即与数据库的对话而不是跨多个事务)的一种方式,这只是设计工作单元的另一种方式.
像任何事情一样,我只是说长时间的谈话可能被滥用或错误地实施.
以下是文档介绍Long对话的方式:
12.1.2.长谈话
每个请求的会话模式不是设计工作单元的唯一方法.许多业务流程需要与用户进行一系列与数据库访问交错的交互.在Web和企业应用程序中,数据库事务跨越用户交互是不可接受的.请考虑以下示例:
- 将打开一个对话框的第一个屏幕.用户看到的数据已加载到特定的会话和数据库事务中.用户可以自由修改对象.
- 用户在5分钟后点击"保存",并期望他们的修改是持久的.用户还希望他们是唯一编辑此信息的人,并且没有发生冲突的修改.
从用户的角度来看,我们称这个工作单元是一个长期运行的对话或应用程序事务.在您的应用程序中有很多方法可以实现它.
第一个天真实现可能会在用户思考期间保持会话和数据库事务处于打开状态,数据库中会保留锁以防止并发修改并保证隔离和原子性.这是一种反模式,因为锁争用不允许应用程序随着并发用户的数量而扩展.
您必须使用多个数据库事务来实现对话.在这种情况下,维护业务流程的隔离成为应用程序层的部分责任.单个对话通常跨越多个数据库事务.如果只有这些数据库事务中的一个(最后一个)存储更新的数据,那么它将是原子的.所有其他人只是简单地读取数据(例如,在跨越多个请求/响应周期的向导式对话框中).这比听起来更容易实现,特别是如果你利用Hibernate的一些功能:
- 自动版本控制:Hibernate可以为您执行自动乐观并发控制.它可以自动检测用户思考期间是否发生了并发修改.在对话结束时检查这一点.
- 分离的对象:如果您决定使用每个请求的会话模式,则在用户思考期间,所有已加载的实例都将处于分离状态.Hibernate允许您重新附加对象并保留修改.该模式称为session-per-request-with-detaached-objects.自动版本控制用于隔离并发修改.
- 扩展(或长)会话:在提交数据库事务并在发生新客户端请求时重新连接后,可以从基础JDBC连接断开Hibernate会话.这种模式称为每次会话会话,甚至不需要重新附加.自动版本控制用于隔离并发修改,并且不允许自动刷新会话,而是显式刷新.
双方 的session-per-请求与独立式的对象 和会话的每个会话都有优点和缺点.这些缺点将在本章后面的乐观并发控制的上下文中讨论.
我在下面添加了一些参考资料,但我建议阅读整个第12章.交易和并发.
| 归档时间： |
|
| 查看次数： |
2073 次 |
| 最近记录： |