IDENTITY 식별자 생성기를 사용할 때 최대 절전 모드가 INSERT 배치를 사용하지 않도록 설정하는 이유는 무엇입니까?

IDENTITY 식별자 생성기를 사용할 때 최대 절전 모드가 INSERT 배치를 사용하지 않도록 설정하는 이유는 무엇입니까?

최대 절전 모드 문서에는 다음과 같이 나와 있습니다.

하이버네이트는 ID 식별자 생성기를 사용하는 경우 JDBC 수준에서 삽입 배치를 투명하게 비활성화합니다.

하지만 내 모든 엔티티는 다음과 같은 구성을 가집니다.

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

위에 이 정체성을 사용할 때는 그래서.

1. 무엇이 문제입니까?IDENTITY?
2. 배치 인서트가 비활성화됩니까?
3. 어떻게 해결해야 합니까?

트랜잭션 기록 후처리

Hibernate는 Persistence Context 플러시를 마지막으로 가능한 순간까지 연기하려고 합니다.이 전략은 전통적으로 트랜잭션 기록(transactional write-backing)이라고 알려져 있습니다.

쓰기 뒤는 논리적 또는 물리적 트랜잭션보다는 최대 절전 모드 플러싱과 더 관련이 있습니다.트랜잭션 중에는 플러시가 여러 번 발생할 수 있습니다.

플러시된 변경 내용은 현재 데이터베이스 트랜잭션에 대해서만 볼 수 있습니다.현재 트랜잭션이 커밋되기 전까지는 다른 동시 트랜잭션에 의해 변경 사항이 표시되지 않습니다.

신원

그IDENTITY발전기가 허용합니다.int아니면bigint요청 시 자동으로 증가되는 열입니다.증분 프로세스는 현재 실행 중인 트랜잭션 외부에서 발생하므로 롤백이 이미 할당된 값을 폐기할 수 있습니다(값 차이가 발생할 수 있음).

증가 프로세스는 더 무거운 트랜잭션 코스 그레인 잠금과 달리 데이터베이스 내부 경량 잠금 메커니즘을 사용하기 때문에 매우 효율적입니다.

유일한 단점은 INSERT 문을 실행하기 전에 새로 할당된 값을 알 수 없다는 것입니다.이러한 제한은 하이버네이트가 채택한 트랜잭션 기록 플러싱 전략을 방해하고 있습니다.이러한 이유로 Hibernates는 다음을 사용하여 엔티티에 대한 JDBC 배치 지원을 사용하지 않도록 설정합니다.IDENTITY발전기

테이블

유일한 해결책은 a를 사용하는 것일 것입니다.TABLE옵티마이저가 지원하는 식별자 생성기.이 생성기는 MySQL에서도 작동하므로 데이터베이스 SEEENCE 지원 부족을 극복합니다.

그러나 발전기의 성능은IDENTITY, 결국 이것은 실행 가능한 대안이 아닙니다.

결론

따라서 MySQL에서는 IDENTITY를 사용하는 것이 여전히 최선의 선택이며 삽입을 위해 배치가 필요한 경우 JDBC를 사용할 수 있습니다.

언급URL : https://stackoverflow.com/questions/27697810/why-does-hibernate-disable-insert-batching-when-using-an-identity-identifier-gen