문제 해결 경험 (2) 썸네일형 리스트형 @Transactional 격리 수준 - 오류 발생 경험 이번 포스팅에서는 @Transaction의 격리수준을 알고 있었지만, 실제 운영환경에서 에러를 냈던 경험에 대해서 포스팅하려고 합니다. 그리고 격리수준에 대해서는 간단하게만 적어보려 합니다. 트랜잭션 격리 수준(4단계) 트랜잭션의 격리 수준이란?? 동시에 여러개의 요청이 들어왔을때, 트랜잭션별로 영향을 끼치는 정도라고 생각하면 될 것 같습니다. 그리고 그 격리 수준에따라 다른 트랜잭션이 변경 된 데이터를 읽을 수 있는지 없는지 결정되게 됩니다. 간단하게 격리 수준을 정리해보면.. 아래와 같이 4단계로 구분이 됩니다. READ_UNCOMMITED(0단계) 1. commited되지 않은 데이터를 읽을 수 있는 격리 수준이기 때문에 데이터의 정합성이 맞지 않을 확률이 큽니다. 2. Dirty Read 발생 가.. Thread를 활용한 비동기 처리 회사에서 신규 고객센터를 개발하는 일을 담당하게 되었습니다.어느 정도 고객센터 개발이 완료되는 시점에서 고객들의 상담 접수 및 상담원들의 상담 완료 처리가 되면 고객들에게 이메일 알림을 보내는 기능을 추가하게 되었고, 실제로 JavaMail 라이브러리만 다운받으면 쉽게 기능 구현을 할 수 있었습니다.기능 구현을 완료한 시점에 테스트를 해 본 결과 상담 접수 시간이 3초 ~ 5초 정도 늘어난 것을 발견하였고, 원인은 이메일 전송 때문이라는 것을 알게 되었습니다.고객센터 상담 건 접수 기본 로직먼저, 간단하게 고객센터의 기본 로직은 4가지 단계로 이루어져 있습니다.1. 고객들의 문의 접수2. AWS S3에 이미지 저장3. 상담원들에게 상담 건 자동 배분4. 이메일 전송(알림용)이메일 전송 부분이 추가 되면서.. 이전 1 다음
