为什么在使用IDENTITY标识符生成器时Hibernate禁用INSERT批处理 [英] Why does Hibernate disable INSERT batching when using an IDENTITY identifier generator
问题描述
Hibernate文档说:
The Hibernate documentation says:
Hibernate透明地在JDBC级别禁用插入批处理，如果 您使用身份标识符生成器.
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;
当我在So上方使用此身份时
When I'm using this identity above So
-
IDENTITY有什么问题? - 是否禁用了批量插入?
- 我该如何解决?
- what's the problem with
IDENTITY? - is the batch insert disabled?
- How can I solve this?
推荐答案
事务性后写式
Hibernate尝试将持久性上下文刷新推迟到最后可能的时刻.传统上，这种策略被称为事务后写.
Transactional write-behind
Hibernate tries to defer the Persistence Context flushing up until the last possible moment. This strategy has been traditionally known as transactional write-behind.
后写与Hibernate刷新更相关，而不是任何逻辑或物理事务.在交易过程中，刷新可能会发生多次.
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.
IDENTITY生成器允许根据需要自动增加int或bigint列.增量过程发生在当前正在运行的事务之外，因此回滚最终可能会丢弃已分配的值(可能会出现值差距).
The IDENTITY generator allows an int or 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.
唯一的缺点是在执行INSERT语句之前我们无法知道新分配的值.这种限制阻碍了Hibernate所采用的事务后写后刷新策略.因此，Hibernates使用IDENTITY生成器为实体禁用JDBC批处理支持.
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.
唯一的解决方案是使用TABLE标识符生成器，该生成器由 pooled-lo 优化器.该生成器也可与MySQL一起使用，因此它克服了对数据库SEQUENCE支持的不足.
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.
因此，在MySQL上，使用IDENTITY仍然是最佳选择，如果需要批量插入，则可以使用JDBC.
Therefore, using IDENTITY is still the best choice on MySQL, and if you need batching for insert, you can use JDBC for that.
这篇关于为什么在使用IDENTITY标识符生成器时Hibernate禁用INSERT批处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
