什么是'扩展会话反模式'？
答案 0 :(得分：5)
扩展（或长期）会话（或 会话每会话 ）是一个可能超出交易持续时间的会话，而不是交易 - 范围会话（或会话每请求）。这不一定是反模式，这是一种实现长对话的方式（即与数据库的对话而不是跨多个事务），这只是另一种设计单位的方式工作。
像任何事情一样，我只是说长时间的谈话可能被滥用或被错误地实施。
以下是文档介绍Long对话的方法：
12.1.2. Long conversations
会话每请求模式是 不是设计单位的唯一方法 工作。许多业务流程都需要 一系列的互动 与之交错的用户 数据库访问。在网络和 企业应用程序，它不是 数据库事务可以接受 跨越用户交互。考虑 以下示例：
- 对话框的第一个屏幕打开。用户看到的数据是 加载在特定的Session和 数据库事务。用户是免费的 修改对象。
- 用户在5分钟后点击“保存”并期望他们的 修改要坚持不懈。 用户也期望他们是 编辑这个的唯一人 信息，没有冲突 修改已经发生。
从用户的角度来看，我们 把这个工作单元称为长期运行 对话或申请 交易。有很多方法可以 在您的应用程序中实现这一点。
第一个天真的实施可能 保持会话和数据库 在用户思考期间交易开放 时间，数据库中保存了锁 防止并发修改和 保证隔离和原子性。 这是一种反模式，因为锁定 争论不允许 应用程序与数字进行扩展 并发用户。
您必须使用多个数据库 交易实施 会话。在这种情况下， 保持业务隔离 过程变得局部 申请的责任 层。通常是单一的谈话 跨越多个数据库事务。 如果只有其中一个，它将是原子的 数据库事务（最后一个） 存储更新的数据。所有其他人 只需读取数据（例如，在 向导式对话跨越几个 请求/响应周期）。这是 比实际更容易实施 声音，特别是如果你利用一些 Hibernate的功能：
- 自动版本控制：Hibernate可以执行自动乐观 你的并发控制。它可以 自动检测是否并发 用户期间发生了修改 想想时间。最后检查一下 谈话。
- 分离的对象：如果您决定使用每个请求的会话模式， 所有加载的实例都将在 用户思考时的分离状态。 Hibernate允许你重新附加 对象并坚持修改。 该模式被称为 会话每个请求与 - 分离的对象。 自动版本控制用于 隔离并发修改。
- 扩展（或长）会话：可以断开Hibernate会话 来自底层的JDBC连接 在数据库事务之后 当a。时已经提交并重新连接 发生新客户端请求。这个 模式被称为 每次会话会话和制作 甚至不需要重新附加。 自动版本控制用于 隔离并发修改和 会议将不被允许 自动刷新，但是 明确地。
<强>这两个 会话每次请求与独立式的对象 和会话每会话有 优点和缺点。这些 缺点将在后面讨论 本章的背景下 乐观并发控制。
我在下面添加了一些参考文献，但我建议阅读整篇Chapter 12. Transactions and Concurrency。