문제 상황

• 통계 시스템은 설문 응답 데이터를 10초마다 스케줄러가 주기적으로 조회하여 통계를 집계하는 스케줄링 방식으로 동작.
• 하지만 지속적으로 응답 데이터가 통계 집계에서 누락되는 현상이 발생.
• ex. 13:59:50 ~ 14:00:00 사이에 생성된 응답 데이터 중 일부(5, 6번)가 누락되어 통계 결과와 실제 응답 수가 일치하지 않음.

응답 데이터

스케줄링

• 스케줄러 동작 시간

  14:00:00 스케줄러

• 집계 데이터 범위 (응답 시간 기준)

  13:59:50 ~ 14:00:00

• 실제 집계된 응답 데이터 id

  [1, 2, 3, 4]

문제원인

• 응답 데이터의 트랜잭션 커밋 시점과 스케줄러 동작 시점 사이의 경합 상태(race condition) 발생.

  

• 응답 데이터 처리시간이 길어질 때, 트랜잭션이 지연되며 응답 데이터가 commit되지 않는 상태가 길어짐

• 13:59:57에 생성된 응답 데이터가 실제 응답 시간은 13:59:59로 기록.

  • 트랜잭션이 지연되며 14:00:01에 commit.
  • 14:00 스케줄러 동작 시점에 해당 데이터는 커밋되지 않아 조회되지 않음.
  • 이후 14:00:10 스케줄러의 조회 범위에 포함되지 않아(응답시간이 13:59:59) 통계에서 누락.

해결 방법 1: 응답 시간을 commit시간으로 기록

응답 시각을 설문의 응답 시간(트랜잭션 시작 시간)이 아닌, DB의 커밋 시각을 기록하여 모든 데이터가 스케줄러의 조회 범위에 포함되도록 시도

• TransactionSynchronization 활용

  • 스프링의 TransactionSynchronization.afterCommit() 의 콜백으로 커밋 시점 이후에 commitTime을 업데이트 하는 방식
  • 커밋 직후에 다시 한 번 UPDATE 쿼리를 날려야 함 → 불필요한 DB I/O 발생 및 트랜잭션 범위가 다시 길어진다
  • 데이터베이스에 동일 엔티티를 두 번 기록해야 하므로 성능 저하 및 복잡성 증가.

• Hibernate 이벤트 리스너 사용

  • :Hibernate의 PostCommitInsertEventListener 또는 PostCommitUpdateEventListener를 사용하여 커밋 이후 동작을 감지하고 commitTime 기록.
  • Hibernate 이벤트 시점은 flush 기준이어서, 실제 DB 커밋 시점과 정확히 일치하지 않을 수 있다. 실제 커밋 시점을 반영하지 못한다.