延迟加载是否工作与事务边界无关。它仅要求打开会话。
但是，何时打开会话取决于您实际上是如何设置SessionFactory的，您没有告诉我们！
SessionFactory.getCurrentSession()实际执行的操作背后有配置！如果您允许使用默认版本的
ThreadLocalSessionContext，而不执行任何管理生命周期的操作，则实际上确实默认是在提交时关闭会话。（因此，通常的观念是，扩展事务边界是延迟加载异常的“解决方案”。）
如果你管理你自己的会话的生命周期与
sessionFactory.openSession()和
session.close()你将能够在会话的生命周期内延迟加载罚款，外事务边界。或者，您可以提供一个子类，
ThreadLocalSessionContext该子类使用所需的边界来管理会话生命周期。还有一些容易获得的替代方法，例如OpenSessionInView过滤器，可以在Web应用程序中使用它来将会话生命周期绑定到Web请求生命周期。
编辑：当然，您也可以只初始化事务内的列表（如果适合您）。我只是认为，当您需要为实体的每个水合作用级别使用某种“标志”参数的新方法签名时，就会导致API变得笨拙。dao.getUser（）dao.getUserWithMailAccounts（）dao.getUserWIthMailAccountsAndHistoricalIds（）等。
编辑2：您可能会发现这对于会话保持打开状态/会话范围与事务范围之间的关系的不同方法很有帮助。（特别是与分离对象的每个请求会话与每个会话的会话的想法。）
- http://community.jboss.org/wiki/SessionsAndTransactions
对话的实际规模取决于您的要求和体系结构。
