매칭글 1개를 작성하면 파일이 최대 5개까지 업로드 될 수 있어 최대 나갈 수 있는 쿼리가 게시글 1개와 (최대)이미지 파일 5개로 총 6번의 DB Query가 발생했습니다.
즉, 불필요하게 TCP Connection을 최대 5번이나 맺는 상황이 발생할 수 있습니다.
TCP Connection 비용: [3-way → 데이터 전송 → 4-way] * 5
해결
그러므로 단 2번의 쿼리를 발생시킬 수 있도록 다량의 데이터를 삽입하는 벌크 연산을 도입하여 쿼리를 최적화 할 수 있었습니다.
하지만 IDENTITY 키 전략은 다른 키전략과는 다르게 JPA에서 제공하는 BulkInsert를 사용하지 못한는 또다른 이슈를 맞이했습니다.
JPA는 기본적으로 영속성 컨텍스트를 사용하면서 해당 키의 정보를 반드시 알아야 합니다.
그렇기 때문에 IDENTITY 전략은 DB에 삽입을 하고 나서야 키를 알아올 수가 있습니다.
[다른 키 전략을 사용하지 않은 이유]
sequance를 사용하지 않는 이유는 lock을 saveAll()메소드가 끝날 때까지 유지하게 되면서 다른 트랜잭션에서 시퀀스 정보를 얻을 수 없는 문제가 발생할 수도 있기 때문에 sequnce 생성은 별도의 트랜잭션에서 처리하고 바로 commit하게 됩니다.
sequence를 얻기위해 별도 트랜잭션에서 처리하는 것은 sequence를 생성하는 동안은 추가 connection이 필요하다는 것을 의미합니다. 그렇기 때문에 connection pool이 부족한 애플리케이션이라면 conncection을 얻기 위한 시간이 더 발생할 수 있다고 합니다. (실제로 connection pool 사이즈를 1로 변경하고 테스트를 해보면 connection을 얻지 못해 실패한다)
