해결된 질문
작성
·
39
1
몇 챕터/몇 강을 수강 중이신가요? 4-8
여기까지 이해하신 내용은 무엇인가요? mysql 내부에서 자체적으로 공유락과 배타락을 사용
어느 부분에서 막히셨나요?
코드의 어떤 로직이 이해가 안 되시나요?
어떤 개념이 헷갈리시나요? 코드상에서 직접적으로 락을 사용하지 않아도 결론적으로 mysql 내부에서 락을 사용하는데 왜 동시성 테스트는 실패하는건가요??
문제 해결을 위해 어떤 시도를 해보셨나요?
에러가 발생했다면 어떤 에러인가요?
현재 작성하신 코드를 공유해주세요
이렇게 구체적으로 알려주시면, 더 정확하고 도움이 되는 답변을 드릴 수 있습니다!
답변 2
1
안녕하세요 모깅님 좋은 질문 해주셔서 감사합니다.
MySQL에서 내부적으로 락을 사용한다는 것은 맞지만, 동시성 테스트가 실패하는 이유는 락의 종류와 범위가 다르기 때문입니다!
MySQL이 내부적으로 사용하는 락들은 주로 데이터 무결성 보장을 위한 것입니다:
Row-level Lock (행 단위 락)
UPDATE, DELETE 시 해당 행에만 배타락(X-Lock) 설정
다른 행에는 영향 없음
매우 짧은 시간만 유지
Foreign Key 검증 락
INSERT 시 참조 무결성 확인을 위해 공유락(S-Lock) 설정
검증이 완료되면 즉시 해제
하지만 애플리케이션에서 발생하는 동시성 문제는 비즈니스 로직 레벨에서 일어납니다:
// 1. 데이터 조회 (락 없음)
Event event = eventRepository.findById(1L); // 현재 참가자: 0명
// 2. 비즈니스 로직 처리 (메모리에서 수행)
event.increaseParticipants(); // 메모리상에서 0 -> 1
// 3. 데이터 저장 (이때만 잠깐 락)
eventRepository.save(event); // DB에 1 저장
MySQL의 내부 락은 개별 SQL 문장의 원자성만 보장합니다
UPDATE event SET participants = participants + 1
← 이런 쿼리라면 안전
하지만 조회 → 계산 → 저장
과정은 여러 단계로 나뉘어져 있어서 보호받지 못함
즉 MySQL 내부 락은 데이터베이스 레벨의 무결성을 보장하지만, 애플리케이션 비즈니스 로직의 동시성 문제는 별도로 해결해야 합니다. 이것이 바로 동시성 테스트가 실패하는 근본적인 이유입니다
더 궁금하신 점 있으시면 언제든 질문 추가로 주세요!!
0
안녕하세요, 인프런 AI 인턴입니다. 모깅님.
MySQL에서의 동시성 제어와 관련한 문제에 대해 질문을 주신 것 같습니다. MySQL이 내부적으로 락을 사용하더라도 직접적인 코드에서 락을 설정하지 않아도 문제가 발생할 수 있는데, 이러한 상황은 설계의 복잡성과 MySQL의 동작 방식에서 오는 것이 일반적입니다.
락의 종류와 적용 범위:
락이 동시성 테스트 실패에 미치는 영향:
격리 수준 설정: 트랜잭션 격리 수준을 INNODB에서 제공하는 높은 수준으로 설정하여 데이터를 안전하게 보호할 수 있습니다. READ COMMITTED 또는 SERIALIZABLE 격리 수준을 시도해보세요.
명시적 락 사용: 필요한 경우 직접적으로 FOR UPDATE
나 LOCK IN SHARE MODE
와 같은 SQL 구문을 사용하여 명시적으로 락을 설정하고 제어할 수 있습니다.
동시성 테스트 전략: 여러 사용자와 트랜잭션이 경합할 수 있는 상황을 시뮬레이션하여 테스트하는 것이 중요합니다. 가능한 한 실제 사용 환경과 유사한 조건 하에서 테스트를 진행해보세요.
관련하여 더 자세한 예제나 설명은 MySQL 동시성 제어에 대한 문제와 해결책을 참조하면 도움이 될 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.