인프런 커뮤니티 질문&답변
작성한 질문수
트랜잭션 락 질문있습니다!
작성
·
6
·
수정됨
0
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.
1. 강의 내용과 관련된 질문을 남겨주세요.
2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.
(자주 하는 질문 링크: https://bit.ly/3fX6ygx)
3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.
(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)
질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.
=========================================
[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? (예/아니오)
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)
3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)
[질문 내용]
안녕하세요 강사님! 강의 잘보고 있습니다🙂
트랜잭션 강의를 듣고나니 mysql에서 table에서 트랜잭션관리 + lock이 필요함을 이해했습니다.
근데 이 강의를 듣고나니 헷갈리는게 고급1편강의에서 lock(reentrant lock, synchronized, cas, 비관적락 같이 임계영역을 보호하는 것) 과 헷갈려 질문하게 되었습니다.
먼저 executor패키지 같은 멀티스레드 경우는 당연히 여러 사용자의 요청을 동시에 처리해야하니 필수적이라고 이해되는데 문제는 lock관련 부분이 헷갈리기 시작했습니다ㅠㅠ
일단 이런 애플리케이션 단의 lock들(reentrantlock synchronized cas 비관적락)은 서버가 여러대 A,B,C서버가 되면 각각의 서버에서만 lock을 관리해서 A서버의 a1스레드 출금로직 과 B서버의 b1스레드 출금로직이 겹칠 수 있다고 하더라구요! 그래서 애플리케이션에서 각 서버에 lock을 걸었어도 mysql단의 lock이 필수적이다. 라고 이해했는데 이러면 애플리케이션단에서 lock들이 존재하는 필요성이 사라져서 의문입니다..ㅠㅠ 그냥 db단에서만 걸어주면 충분하지 않나요?? 어차피 걸어도 서버 분산화가되면 소용없는거 아닌가요..?
그래서 찾아본 해결방안이 애플리케이션 java단의 출금메서드에 @Transactional을 걸고 관련 repository메서드들에 @Lock(PESSIMISTIC_WRITE)를 걸면 SELECT --- FOR UPDATE가 걸려서 db 단에서 lock이걸린다.
reentrantlock같은건 쓰지 않아도 된다.
로 이해했는데 맞을까요?
그렇다면 이러한 lock들은 단일서버에서만 통하니 실무에선 잘 사용하지 않는것인지...
배운지식들을 합치니까 헷갈리기 시작하네요😇😇
강사님께선 어떻게 하시는지 궁금합니다!!!
긴 질문 읽어주셔서 감사드립니다🥰
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. 한슬기님.
MySQL에서 트랜잭션과 락에 대해 궁금해하시는 점 잘 이해했습니다. 애플리케이션 계층에서의 락과 데이터베이스 계층에서의 락은 각각 다르게 사용되며, 각자의 역할이 있는 점을 고려해야 합니다.
애플리케이션 계층에서의 락
- ReentrantLock, synchronized: 주로 멀티 스레드 환경에서 자원(코드 블록, 객체 등)을 보호하기 위해 사용됩니다. 단일 프로세스(서버) 내에서 작동하므로, 서버가 여러 대로 분산된 경우 다른 서버의 스레드와는 충돌 없이 동작할 수 있습니다.
데이터베이스 계층에서의 락
- @Transactional과 데이터베이스 락: 데이터베이스 트랜잭션 관리를 통해 동시에 여러 트랜잭션이 동일한 데이터에 접근할 때 일관성을 보장합니다. 특히
PESSIMISTIC_WRITE같은 락을 사용하면, 트랜잭션이 완료될 때까지 다른 트랜잭션이 데이터를 수정하지 못하도록 하기 때문에 분산된 환경에서 데이터의 일관성을 더 잘 보장할 수 있습니다.
이해를 돕는 결론
- 애플리케이션 락 vs 데이터베이스 락: 애플리케이션 단의 락은 프로세스 내의 병행 문제를 해결하는 반면, 데이터베이스 락은 여러 프로세스(심지어 여러 서버)에 걸쳐 동작하는 트랜잭션을 안전하게 관리합니다.
- 서버가 여러 대인 경우: 같은 데이터베이스에 동시에 접근해야 할 경우, 데이터베이스 락을 통한 관리는 매우 중요합니다. 애플리케이션 락은 이와 별개로 단일 서버 내의 자원 접근을 제어하는 데 효과적입니다.
- 실무에서의 사용 예: 비즈니스 요구사항에 따라 데이터 일관성을 어디에서 관리할지를 결정해야 합니다. 실용적으로는 두 방식 모두 사용될 수 있고, 특히 금융 같은 민감한 데이터 처리에서는 데이터베이스 락이 중요한 역할을 하게 됩니다.
ReentrantLock은 특정 조건에서 여전히 유용하며, 서버 간의 상호작용이 없는 환경에서는 효과적으로 사용할 수 있습니다. 그러나, DB 트랜잭션으로 보장할 수 있는 부분이 있다면 DB 처리를 적극 활용하는 것이 일반적입니다.
해당 사항은 JPA와 관련한 락 처리 방법에 대한 다른 질문을 참고하시면서 더 깊이있는 이해를 도울 수 있도록 하시면 좋겠습니다. 궁금증이 해소되시길 바라며, 더 필요한 정보가 있으시면 언제든지 질문해주세요. 😊
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.