使用DataSourceTransactionManager进行ORM持久化而不是HibernateTransactionManager可以吗？ [英] Is it ok to use DataSourceTransactionManager for ORM persistence instead of HibernateTransactionManager?

问题描述

我正在调试我们的webapp。它被配置为在启动时创建一个DataSourceTransactionManager bean和一个HibernateTransactionManager bean。这不是有意的，而是由第三方依赖造成的。效果似乎是良性的。通过调试我看到的是，当我们通过基于Hibernate的DAO持久对象时 - 调用DataSourceTransactionManager而不是HibernateTransactionManager（这两个bean都称为transactionManager）。 Spring Javadoc意味着（我认为，现在重新阅读它）这对当地资源来说很好 - 这就是我们的情况。即它不是一个基于分布式JTA的环境。

我的问题是 - 不使用HibernateTransactionManager进行基于ORM的持久性会有什么负面影响。我可以改变配置，使HibernateTransactionManager通过我们DAO的@Transactional注解的限定符来使用。

在简单的单元测试，集成测试设置但我更关心的是，当我们有成千上万的用户和高水平的并发时，扩展到全部产品量。

TIA，
希望这不是不要太模糊。

Spring 3.0.x顺便说一句。

这是Spring 3.1文档。

第11.9节常见问题的解决方案。

使用正确的PlatformTransactionManager实现基于
您选择的交易技术和需求。

解决方案

这会打击我错误的，并会导致问题。如果没有hibernate txn管理器，所有对HibernateOperations的调用都将在一个事务之外并且在一个单独的会话中，可能使用自动提交。因此，如果发生错误，您可能会发现一切正常，您可能会发现您希望回滚的更改不会发生。

请尝试以下操作来检查 p>

• 开始转换


• 保存内容
  
• 抛出异常
li>

• commit

检查数据库中是否显示'something'。

另一张支票是

• 开始转帐


• 加载内容
  
• 从某个对象访问另一个对象的关系并访问此相关对象的属性（而不是pk）
  

您可能会发现最后一次调用会导致异常，因为会话并未从加载保持打开，因为封闭txn不受hibernate txn管理器管理。

I am debugging our webapp. It is configured to create a DataSourceTransactionManager bean and also a HibernateTransactionManager bean on startup. This is not intentional but is caused by a 3rd party dependency. The effect appears to be benign. What I'm seeing via debugging is that when we persist an object via a Hibernate based DAO - the DataSourceTransactionManager is invoked and not the HibernateTransactionManager (the beans both are called 'transactionManager'). The Spring Javadoc implies (I think, re-reading it now) this is fine for local resources - which is our situation. I.e. its not a distributed JTA based environment.

My question is - is there any negative impact of not using the HibernateTransactionManager for ORM based persistence. I can change the config to make the HibernateTransactionManager be used via a qualifier on the @Transactional annotation on our DAOs.

Things are working fine in simple unit test, integration test setup but I am more concerned about scaling to full production volumes when we'll have thousands of users and a high level of concurrency.

TIA, hope this isn't too obscure.

Spring 3.0.x BTW.

This is in the Spring 3.1 docs.

Sec 11.9 "Solutions to Common Problems".

Use the correct PlatformTransactionManager implementation based on your choice of transactional technologies and requirements.

解决方案

This would strike me as wrong and will cause problems. Without the hibernate txn manager all calls made to HibernateOperations will be outside a transaction and on a separate session, possibly using auto-commit. So it might appear that everything is fine when an error occurs you may find changes you would expect to be rolled-back aren't.

Try the following to check

• begin tran
• save something
• throw exception
• commit

Check whether the 'something' appears in the DB or not.

Another check would be

• begin tran
• load something
• access a relation to another object from something and access a property (not the pk) of this related object

You might find the last call causes an exception as the session was not kept open from the load because the enclosing txn is not managed by the hibernate txn manager.

这篇关于使用DataSourceTransactionManager进行ORM持久化而不是HibernateTransactionManager可以吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！