[BE] refactor: 트랜잭션 격리레벨 serializable을 제거한다.

[dongho108]

As-is

• 현재 InterviewService의 create메서드에는 트랜잭션 격리레벨 serializable 이 걸려있습니다.

To-be

• serializable 옵션 제거
• DB에 따로 락을 걸지 않는다.

[dongho108]

이 이슈에 대한 이유와 학습내용은 조만간 여기 코멘트에 달아놓겠습니다!

[dongho108]

터놓고의 동시성 문제

과거

동시에 인터뷰를 신청하면 두개가 신청됐었습니다.

• 이유 : Interview가 AvailalbeDateTime 의 Time 값을 복사해 생성했기 때문에 DB에 동시에 같은 시간으로 생성요청을 하면 그대로 들어갔습니다.

현재

• 지금은 Interview가 AvailableDateTimeId를 가지고 생성되고, unique 제약조건이 걸려있기 때문에 두개가 신청되지는 않습니다.

그럼 동시에 신청이 들어온다면

• used 검증 통과

  private void validateUsedTime(final Interview interview) {
        if (interview.getAvailableDateTime().isUsed()) {
            throw new InterviewInvalidException(USED_BY_OTHER);
        }
  }

  • (이 검증은 같은 id로 USED로 들어오는 것을 검증하려는 목적이 아니라 그냥 시간 상태가 USED인 것으로는 인터뷰를 생성하지 못한다는 의미입니다.)

• 그러면 DB에서 unique가 터짐

  @OneToOne
  @JoinColumn(name = "available_date_time_id", unique = true)
  private AvailableDateTime availableDateTime;

결론

• 어차피 unique 제약조건으로 동시에 같은 Interview가 생성되지 않습니다.
• 격리단계를 다시 내리고 DB 의 예외 검증을 500으로 터지지 않게 하면 됩니다.