问题描述
什么是'扩展会话反模式'？
What is 'Extended Session Antipattern' ?
推荐答案
扩展（或长期）会话（或 会话每会话 ）是一个可能超出事务持续时间的会话，而不是事务范围的会话（或每个请求的会话） 。这不一定是反模式，这是实现长对话（即与数据库的对话而不是跨多个事务）的一种方式，这只是另一种设计单位的方式工作。
An extended (or Long) session (or session-per-conversation) is a session that may live beyond the duration of a transaction, as opposed to transaction-scoped sessions (or session-per-request). This is not necessarily an anti-pattern, this is a way to implement Long conversations (i.e. conversations with the database than span multiple transactions) which are just another way of designing units of work.
就像任何事情一样，我只是说长时间的对话可能会被滥用或被错误地实施。
Like anything, I'd just say that long conversations can be misused or wrongly implemented.
以下是文档介绍长对话的方式：
Here is how the documentation introduces Long conversations:
- 打开对话框的第一个屏幕。用户看到的数据是在特定会话和
数据库事务中加载的
。用户可以免费
来修改对象。 - 用户在5分钟后点击保存，并期望他们的
修改是持久的。
用户还希望他们是
唯一编辑此
信息的人，并且没有发生冲突的
修改。
从用户的角度来看，我们
将这个工作单元称为长期运行的
对话或申请
交易。有很多方法可以在你的应用程序中实现这个
。
From the point of view of the user, we call this unit of work a long-running conversation or application transaction. There are many ways to implement this in your application.
第一个天真的实现可能是
保持会话和数据库
事务打开在用户认为
时间内，数据库中保存锁定
以防止并发修改，
保证隔离和原子性。
这是一种反模式，因为锁定
争用不允许
应用程序与并发用户数
一起扩展。
A first naive implementation might keep the Session and database transaction open during user think time, with locks held in the database to prevent concurrent modification and to guarantee isolation and atomicity. This is an anti-pattern, since lock contention would not allow the application to scale with the number of concurrent users.
您必须使用多个数据库
交易来实现
对话。在这种情况下，
维护业务
流程的隔离成为应用程序
层的部分
责任。单个对话通常
跨越多个数据库事务。
如果只有这些
数据库事务中的一个（最后一个）
存储更新的数据，那么它将是原子的。所有其他
只是读取数据（例如，在
向导式对话框中，跨越几个
请求/响应周期）。这比
声音更容易实现
，特别是如果你使用一些
的Hibernate功能：
You have to use several database transactions to implement the conversation. In this case, maintaining isolation of business processes becomes the partial responsibility of the application tier. A single conversation usually spans several database transactions. It will be atomic if only one of these database transactions (the last one) stores the updated data. All others simply read data (for example, in a wizard-style dialog spanning several request/response cycles). This is easier to implement than it might sound, especially if you utilize some of Hibernate's features:
- 自动版本控制：Hibernate可以为您执行自动乐观的
并发控制。它可以
自动检测用户
思考时间内是否发生并发
修改。在对话的最后
处检查这一点。 - 分离的对象：如果您决定使用每个请求的会话模式，
所有已加载的实例将是在用户思考期间的
分离状态。
Hibernate允许您重新附加
对象并保留修改。
该模式称为
session-per-request-with-detached-objects。
自动版本控制用于
隔离并发修改。 - 扩展（或长）会话：Hibernate会话可以从
断开连接数据库事务已提交
之后的基础JDBC连接
，当发生
新客户端请求时重新连接。这个
模式被称为每次会话
会话，并且甚至不需要重新附加
。
自动版本控制用于
隔离并发修改和
会话将不允许自动刷新
，但明确
。
- Automatic Versioning: Hibernate can perform automatic optimistic concurrency control for you. It can automatically detect if a concurrent modification occurred during user think time. Check for this at the end of the conversation.
- Detached Objects: if you decide to use the session-per-request pattern, all loaded instances will be in the detached state during user think time. Hibernate allows you to reattach the objects and persist the modifications. The pattern is called session-per-request-with-detached-objects. Automatic versioning is used to isolate concurrent modifications.
- Extended (or Long) Session: the Hibernate Session can be disconnected from the underlying JDBC connection after the database transaction has been committed and reconnected when a new client request occurs. This pattern is known as session-per-conversation and makes even reattachment unnecessary. Automatic versioning is used to isolate concurrent modifications and the Session will not be allowed to be flushed automatically, but explicitly.
两个
会话每请求分离对象
和会话每会话有
优缺点。这些
的缺点稍后将在
乐观并发控制的上下文中讨论。
Both session-per-request-with-detached-objects and session-per-conversation have advantages and disadvantages. These disadvantages are discussed later in this chapter in the context of optimistic concurrency control.
我在下面添加了一些参考文献，但我建议阅读整个。
I've added some references below but I suggest reading the whole Chapter 12. Transactions and Concurrency.
- Hibernate核心参考指南
- Hibernate Core Reference Guide
- 12.1.2. Long conversations
- 12.3. Optimistic concurrency control
这篇关于交易的扩展会话的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！