인프런 커뮤니티 질문&답변
작성한 질문수 18
Transactional 질문 있씁니다.
작성
·
80
·
수정됨
0
[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? (예/아니오)
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)
3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)
[질문 내용]
현재 재직중인 직장 소스를 보면 트랜잭션을 걸어야하는 서비스단 메서드에 @Transactional의 격리 수준이 READ UNCOMMITTED 로 모두 되어있습니다. 하나도 빠짐없이.. 상사분의 말로는 테이블 락 발생을 방지하기 위해 이렇게 한다는데...
영한님의 의견이 궁금합니다. 제가 생각했을때 이는 적합하지 않은 방법같거든요. 정합성이 깨질뿐더러 테이블 락은 다른 방법으로 해결해야지 이건 아닌것 같더라구요..
답변 기다리겠습니다!
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. backendman님.
READ UNCOMMITTED 격리 수준을 사용하는 것은 일반적으로 권장되지 않는 방법입니다. 이 격리 수준은 트랜잭션 내에서 아직 커밋되지 않은 변경 사항을 다른 트랜잭션에서 읽을 수 있도록 허용하므로, 데이터 정합성이 깨질 수 있는 위험이 큽니다. 따라서 데이터 일관성을 보장해야 하는 시스템에서는 위험 요소가 될 수 있습니다.
READ UNCOMMITTED의 문제점:
- Dirty Read: 커밋되지 않은 변경 사항을 다른 트랜잭션에서 읽을 수 있어서, 나중에 롤백되면 잘못된 데이터를 참조할 위험이 있습니다.
- 데이터 일관성 문제: 여러 사용자나 프로세스가 동시에 데이터를 읽고 쓸 때 데이터의 정합성을 보장하지 못합니다.
테이블 락을 방지하는 다른 방법:
- 더 높은 격리 수준 사용: 일반적으로 READ COMMITTED 또는 REPEATABLE READ를 사용하는 것이 기본적인 데이터 무결성을 보장할 수 있습니다.
- Optimistic Locking: 락을 사용하지 않고, 업데이트가 충돌할 경우에만 처리하는 방식입니다.
- Pessimistic Locking의 클러스터드 인덱스 사용: 인덱스를 통해 데이터 검색 및 업데이트 성능을 향상시키는 방법도 고려해볼 수 있습니다.
회사의 특정 상황이나 비즈니스 로직에 따라 차이가 있을 수 있지만, 일반적으로는 READ COMMITTED 이상을 사용하는 것이 좋습니다. 더 깊은 성능 최적화나 데이터 충돌 방지 문제에 대해서는 아키텍처 설계 시 고려해보아야 할 요소입니다.
참고로, 유사한 질문이 트랜잭션 동시성 이슈 관련 질문 드립니다 게시물에서 다루어진 사례가 있으니, 확인해 보시기 바랍니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.