在使用身份标识符生成器时，Hibernate禁用插入批处理 [英] Hibernate disabled insert batching when using an identity identifier generator

问题描述

Hibernate文档说：
$ b

如果
使用身份标识符生成器，​​Hibernate将在JDBC级别禁用插入批处理。

但是我所有的实体都有这样的配置：

  @Id 
 @GeneratedValue（strategy = javax.persistence.GenerationType.IDENTITY）
 private Integer id; 
  

当我在上面使用这个身份时

1. IDENTITY ？


2. 是否禁用批量插入？


3. 如何解决此问题？
   

解决方案

Hibernate试图推迟持久性上下文刷新，直到最后一刻。这种策略传统上被称为交易记录 。



写后跟更多地涉及到Hibernate刷新，而不是任何逻辑或物理事务。在事务处理期间，刷新可能会多次发生。



刷新的更改仅对当前数据库事务可见。在提交当前事务之前，其他并发事务不会看到任何更改。 IDENTITY生成器允许整数/ bigint列根据需要自动递增。增量过程发生在当前正在运行的事务之外，所以回滚可能最终会丢弃已分配的值（可能会发生值差距）。



增量过程非常高效，因为它使用数据库内部轻量级锁定机制，而不是更重量级的事务性粒度锁定。



唯一的缺点是我们无法知道在执行INSERT语句之前新分配的值。这个限制阻碍了Hibernate采用的事务性写入冲洗策略。因此，Hibernates禁用了对使用IDENTITY生成器的实体的JDBC批处理支持。


1. 唯一的解决方案是使用一个TA​​BLE标识符生成器，​​并由一个。该生成器也适用于MySQL，因此它克服了缺乏数据库SEQUENCE支持。但是， the TABLE生成器的性能比IDENTITY差，所以最终这不是一个可行的选择。因此，使用IDENTITY仍然是MySQL的最佳选择，如果您需要批量插入，你可以使用jOOQ 。 Hibernate和jOOQ是一个很好的组合。

The Hibernate documentation says:

Hibernate disables insert batching at the JDBC level transparently if you use an identity identifier generator.

But all my entities have this configuration:

@Id
@GeneratedValue(strategy = javax.persistence.GenerationType.IDENTITY)
private Integer id;

When I'm using this identity above So

1. what's the problem with IDENTITY ?
2. is the batch insert disabled?
3. How can I solve this?

解决方案

1. Hibernate tries to defer the Persistence Context flushing up until the last possible moment. This strategy has been traditionally known as transactional write-behind.

   The write-behind is more related to Hibernate flushing rather than any logical or physical transaction. During a transaction, the flush may occur multiple times.

   The flushed changes are visible only for the current database transaction. Until the current transaction is committed, no change is visible by other concurrent transactions.

2. The IDENTITY generator allows an integer/bigint column to be auto-incremented on demand. The increment process happens outside of the current running transaction, so a roll-back may end up discarding already assigned values (value gaps may happen).

   The increment process is very efficient since it uses a database internal lightweight locking mechanism as opposed to the more heavyweight transactional course-grain locks.

   The only drawback is that we can’t know the newly assigned value prior to executing the INSERT statement. This restriction is hindering the "transactional write behind" flushing strategy adopted by Hibernate. For this reason, Hibernates disables the JDBC batch support for entities using the IDENTITY generator.

3. The only solution would be to use a TABLE identifier generator, backed by a pooled-lo optimizer. This generator works with MySQL too, so it overcomes the lack of database SEQUENCE support. However, the TABLE generator performs worse than IDENTITY, so in the end, this is not a viable alternative. Therefore, using IDENTITY is still the best choice on MySQL, and if you need batching for insert, you can use jOOQ for that. Hibernate and jOOQ are a great combo.

这篇关于在使用身份标识符生成器时，Hibernate禁用插入批处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！