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