요약
이슈: 키 매핑 전략인 IDENTITY 메커니즘에 의해 벌크 연산을 사용하지 못하는 문제를 맞이했습니다.
해결: 시퀀스 전략은 Lock에 의해 성능이 저하될 우려가 있어 채택하지 않고 JDBC Template를 사용하여 성능적 측면을 향상시킴과 동시에 이슈를 해결했습니다.
문제점
IDENTITY 키 전략은 다른 키전략과는 다르게 JPA에서 제공하는 BulkInsert를 사용하지 못한는 또다른 이슈를 맞이했습니다.
원인 분석
JPA는 기본적으로 영속성 컨텍스트를 사용하면서 해당 키의 정보를 반드시 알아야 하기 때문에 IDENTITY 전략은 DB에 삽입을 하고 나서야 키를 알아올 수가 있습니다.
해결
JdbcTemplate을 이용하여 해결했습니다.
추가 고려사항
[다른 키 전략을 사용하지 않은 이유]
sequance를 사용하지 않는 이유는 lock을 saveAll()메소드가 끝날 때까지 유지하게 되면서 다른 트랜잭션에서 시퀀스 정보를 얻을 수 없는 문제가 발생할 수도 있기 때문에 sequnce 생성은 별도의 트랜잭션에서 처리하고 바로 commit하게 됩니다.
sequence를 얻기위해 별도 트랜잭션에서 처리하는 것은 sequence를 생성하는 동안은 추가 connection이 필요하다는 것을 의미합니다. 그렇기 때문에 connection pool이 부족한 애플리케이션이라면 conncection을 얻기 위한 시간이 더 발생할 수 있다고 합니다. (실제로 connection pool 사이즈를 1로 변경하고 테스트를 해보면 connection을 얻지 못해 실패한다)
lock으로 인해 동시성이 떨어지고, 추가적인 connction이 필요한 이유로 인해 Table 키 전략 을 권장하지 않는 글도 존재합니다.
그렇기 때문에 키 전략은 그대로 유지하고 벌크 연산을 쓸 수 있는 방법들 중 java의 표준 스펙인 JDBC 기반으로 하기로 결정했습니다. 또한 많은 성능 측정 부분에서 JDBC가 가장 빠른 응답을 기대할 수 있기도 하기 때문입니다.
