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