java - getCurrentSession 在网络中 hibernate

Question

我正在使用 hibernate 和 jsp/servlet 编写一个基于 Web 的应用程序。我已经阅读了 sessionFactory.getCurrentSession 和 sessionFactory.openSession 方法。我知道它们之间的基本区别(使用 getCurrentSession 您不必关闭连接，当您提交事务时，您的 session 将自动关闭)。根据我的理解，我们应该选择 getCurrentSession 并通过 session-per-request 来完成。

让我们考虑以下场景:

1. 方法 A 调用 getCurrentSession 并获取当前 session
   
2. 在方法 A 中，使用步骤 1 中的 session 启动事务
   
3. 方法 A 调用方法 B，方法 B 也有 getCurrentSession 并启动事务
   
4. 方法 B 提交其事务
   
5. 控制返回到方法 A，它也提交事务
   

现在我的问题是

1. 第 1 步和第 3 步中找到的 session 是否是同一个 session ？
   
2. 如果问题 1 的答案是肯定的，那么它将如何处理步骤 4 中的提交？理想情况下，它应该在那里自己关闭 session ，并且应该在第 5 步抛出异常。
3. 如果问题 1 的答案是否定的，那么您如何处理这种情况？
   

Answer 1

Will the session found in step 1 and step 3 will be the same session?

它们应该是相同的，这是 getCurrentSession() 契约(Contract)的一部分，只要单位为工作尚未完成(即事务已提交或回滚)。 Java Persistence with Hibernate 是这样说的(第 481 页):

All the data-access code that calls getCurrentSession() on the global shared SessionFactory gets access to the same current Session — if it’s called in the same thread. The unit of work completes when the Transaction is committed (or rolled back). Hibernate also flushes and closes the current Session and its persistence context if you commit or roll back the transaction. The implication here is that a call to getCurrentSession() after commit or rollback produces a new Session and a fresh persistence context.

您可能还想阅读 Session#beginTransaction() 的 javadoc。说。

If the answer for the question 1 is yes, then how would it handle the commit in step 4. Ideally it should close the session there itself and should give error at step 5.

第 4 步应该没问题，Session 将被刷新，Transaction 将被提交并关闭 Session。但我预计第 5 步会因 TransactionException 而失败(这是我的赌注)。但是让我引用 Transaction 的 javadoc :

A transaction is associated with a Session and is usually instantiated by a call to Session.beginTransaction(). A single session might span multiple transactions since the notion of a session (a conversation between the application and the datastore) is of coarser granularity than the notion of a transaction. However, it is intended that there be at most one uncommitted Transaction associated with a particular Session at any time.

如上所述，我们正在讨论一些不应该发生的事情(即设计问题)。