在将Hibernate 3升级到Hibernate 4之后，我被迫从基于spring的应用程序中删除HibernateTemplate。为了使Hibernate会话可用，我必须使用比以前更一致的事务定义。这要求我向服务层添加一个事务通知，并密切关注执行只读数据库操作的后台线程。
我有两个数据源（我必须使用两个不同的数据库），第一个用于几乎每个应用程序请求，第二个仅用于特殊（例如，1000个请求中的1个）请求。最简单的方法是使用方面将两种请求类型包装在两个数据库的事务中（我不必确定哪些请求需要哪个数据库），但我想知道这其中涉及的开销。是否将实际的数据库连接获取和事务逻辑（如提交等）推迟到执行实际的查询？或者我的方法是否会导致大量（实际上未使用的）事务被启动和提交？
为了澄清，我有两个数据源，两个事务管理器，两个(相同的)“inServiceLayer”切入点的两个事务通知。
感谢您的任何帮助！
“使用方面将两种请求类型包装在事务中”的确切含义是什么？您的问题表明您的应用程序没有正确分层。您应该具有某种类型的数据访问层，其中事务逻辑以声明方式 （@Transactional） 或编程方式 （事务模板） 应用。这意味着未命中数据库的请求将永远不会打开事务。
编辑:< br >如果不能选择适当的分层，您肯定会招致事务处理的开销。Spring中用于事务划分的标准工具并没有实现这种您想要的“惰性/按需”事务初始化。证明这一点的最简单方法是在您使用的事务管理器上启用调试/跟踪级别的日志记录。
我首先没有考虑开销，我在这里看到的最大问题是您的方法存在根本缺陷。假设某些逻辑可以访问DB-1和DB-2，并且在您在DB-1中提交后，当您尝试提交到DB-2时，发生了一些问题，需要回滚到DB-2的txn，您将在DB-1和DB-2中遇到不一致的数据，因为DB-1中的事务已经提交。
您的案例应该更好地利用分布式事务（我希望您的数据库都支持 XA），因此您在 Spring 点切中只有 1 个（分布式）事务需要处理。而且，我相信（尽管我不确定）正常的 XA 事务不会在所有资源中盲目创建底层事务（即底层 txn 仅在需要时创建）。
因此，使用分布式 txn 可以为您提供更正确、更具体、更易于维护且（可能）更少浪费资源的实现。
进一步研究您的容器的相关设置。
