[Spring Batch] Paging 기반의 ItemReader 사용 시 발생하는 데이터 건너뛰기 현상 (해결 방법 2가지)

1. 문제 상황

데이터베이스를 기준으로 ItemReader의 구현체를 나눌 때, Cursor Based ItemReader과 Paging Based ItemReader으로 나눌 수 있다.

 

Cursor 기반의 ItemReader의 경우, 데이터베이스 커넥션을 지속적으로 독점으로 사용하여 처리가 완료되는 시점까지 커넥션을 놓아주지 않기 때문에, 경우에 따라 성능상에 영향을 줄 수 있다.

 

따라서 Paging 기반의 ItemReader를 선택했고 최근에 스케줄러와, 배치 로직을 개발했다. 

하지만 실제 로직 수행 결과는 원하는데로 되지 않았고, 몇 개의 데이터를 건너뛴채로 수행되었다. 

 

 

 

나의 배치 로직은 특정 조건을 만족하면 PENDING 중이던 Apply를 CANCELED로 변경해주는 것이다. 사진에서 work_date_id가 1인 데이터는 전부 CANCELED로 변경되야 하지만 4개의 데이터 중 2개만 바뀐 것을 볼 수 있다. 

 

 

 

 

 

 

2. 원인

원인은 변경된 데이터 때문이다. 

 

 

만약 아래의 쿼리를 날린다면 다음과 같이 조회될 것이다.

SELECT * FROM Pay 
WHERE successStatus = false 
offset 0 limit 10

 

 

이 조회된 데이터를 Update 해보자.
여기서 중요한 것은 조회한 데이터를 Update할 때 변경된 필드가 조회할 때 조건에 사용되는 것이다.

이 Update로 인해서 이제 테이블에는 false인 데이터가 40개만 존재한다.

 

 

이 상태에서 다음 Paging 쿼리를 실행한다면 어떻게 될까??

SELECT * FROM Pay 
WHERE successStatus = false 
offset 11 limit 10

 

 

조회 결과는 다음과 같다.

 

40개 데이터에서 11번째 부터인 데이터를 가져오게 된다.

 

앞서 실행된 쿼리에서 대상을 Update하여 제외되어 실제로 21번째인 데이터가 11번째 데이터로 조회가 됩니다.

 

그러다보니 11번째 데이터부터 20번째까지 데이터가 조회되지 않는다.

 

 

 

 

 

3. 해결 방안

 

1. Cursor 이용

가장 간단한 해결 방안은 cursor 기반 read 방식으로 변경하는 것이다. 

Cursor는 한번 커넥션을 맺고 Database Cursor를 옮기는 방식이기 때문에 앞서 조회했던 결과가 바뀐다고 다음 조회에 영향을 미치지 않는다.

 

Paging 기반의 이점을 살리면서 조회한 데이터를 변경할 수 있는 방법은 없을까??

PagingReader 오버라이딩을 통해 해결할 수 있다. 

 

2. PagingReader 커스텀

Update될때마다 대상 데이터 범위가 줄어드니, 일부러 Page 번호를 계속 변경시키지 않고 0번째로 고정시키는 것이다. 

 

    @Bean
    public ItemReader<Apply> applyReader() {
        LocalDate tomorrow = LocalDate.now().plusDays(1);
        JpaPagingItemReader<Apply> reader = new JpaPagingItemReader<>() {
            @Override
            public int getPage() {
                return 0;
            }
        };
        reader.setName("applyReader");
        reader.setPageSize(1);
        reader.setEntityManagerFactory(entityManagerFactory);
        reader.setQueryString("select a from Apply a join fetch a.workDate w join fetch a.member m join fetch a.workDate.jobPost j where w.workDate <= :tomorrow and a.status = 'PENDING'");
        Map<String, Object> parameters = new HashMap<>();
        parameters.put("tomorrow", tomorrow);
        reader.setParameterValues(parameters);
        return reader;
    }

 

모든 쿼리에서 아래 사진과 같이 offset이 0으로 고정됐고 건너 뛰는 현상 없이 모든 데이터가 정상적으로 바뀌는 것을 확인할 수 있었다. 

 

 

 

 

 

 

 

4. 결론

DB Connection 시간과 메모리를 고려했을 때는 Paging 방법이 더 좋다. 물론 서버가 Connection 시간과 메모리를 받쳐줄 수 있다면 Cursor방식이 더 간편하고 빠르고 좋은 것 같다.

 

다만, Paging을 선택할 경우 정렬, 누락 데이터 등에 신경쓰면서 개발해야 한다.