休眠批量更新导致查询需要永久完成

Article实体是Product实体的子类。他们的继承策略是joined。 Article#flag是一个布尔属性，我想为所有文章设置false。因此，我做休眠批量更新导致查询需要永久完成

Query query = entityManager.createQuery("update Article set flag=:flagValue"); 
query.setParameter("flagValue", false); 
query.executeUpdate();

我预计这导致一个单一的SQL语句对数据库应该完成相当快。相反，Hibernate填充一个临时表（它并不在物理上存在于数据库中），并运行一个查询语句即。更新后：

insert into HT_article select article0_.id as id from schema.article article0_ inner join schema.product article0_1_ on article0_.id=article0_1_.id 

update schema.article set flag=0 where (id) IN (select id from HT_article)

实际的更新语句采用“永远”来完成和锁定受影响的文章从而导致其他交易锁定异常。我的意思是永远意味着超过一个小时的13万篇文章。

这种行为的解释是什么？我如何解决这个问题？除了运行本机查询我的意思是......

更新2011-05-12：因为在查询时慢，我提交了错误的，它是非常缓慢的 - >http://opensource.atlassian.com/projects/hibernate/browse/HHH-5905

来源

2010-12-10 Marcel Stör

值得一提的是，也'查询查询= getEntityManager（）的createQuery（ “更新第一套标志=假where articleNumber in（：articleNumbers）“）; query.setParameter（”articleNumbers“，articleNumbers）;'导致同样非常缓慢的处理我们在HT_article表中。 – 2010-12-13 09:30:34

因为你'使用InheritanceType.JOINED，Hibernate别无选择，只能统一子类及其基类。

如果您切换到InheritanceType.TABLE_PER_CLASS（http://openjpa.apache.org/builds/1.0.2/apache-openjpa-1.0.2/docs/manual/jpa_overview_mapping_inher.html）你想避免这种情况，让你的表现回来。但我相信你使用的是JOINED有一个原因:-(

来源

2011-05-11 06:19:18 millhouse

我不明白这个说法。如果“标志”是Article（子类）的成员，而不是产品，为什么Hibernate必须统一类？顺便说一句，回到12月，我开始http://lists.jboss.org/pipermail/hibernate-dev/2010-December/005873.html。其中一个回应指向http://in.relation.to/Bloggers/MultitableBulkOperations和http://in.relation.to/Bloggers/BulkOperations，其中解释幕后可能发生的事情。 – 2011-05-12 21:49:58

我正在使用hibernate的InheritanceType.JOINED，并面临类似的问题，其中hibernate插入到临时表中，并花了很长时间来删除实体。使用createQuery和executeUpdate删除造成该问题的记录。使用session.delete(entity)这解决了问题，我开始。

来源

2015-05-12 10:49:44 Taher

休眠批量更新导致查询需要永久完成

回答

相关问题