인프런 커뮤니티 질문&답변
작성한 질문수
NamedLock 테스트 실패
작성
·
78
·
수정됨
0
안녕하세요 상용님 좋은 강의 너무 잘 듣고 있습니다.
namedlock부분에서 테스트 코드를 돌리는데 connectiontimeout 이후 테스트가 실패하여 질문 드리려 합니다.
문제상황
maximum-pool-size를 40으로 설정 후 테스트를 돌리면 다음과 같은 에러가 터지면서 테스트가 실패합니다.
사진에서와 같이 40개 스레드가 락획득을 시도한 후, 30초 후 락획득 시도조차 하지못한 60개의 스레드에서 타임아웃이 납니다.
이후 락 획득을 기다리던 스레드하나가 타임아웃이 나고 나머지 스레드들이 39번의 재고 감소 로직을 실행합니다.
추측
제가 추측한 것은 다음과 같습니다.
1. 현재 transactional propagation requiresnew로 되어있기에 하나의 재고 감소 로직 당 2개의 connection을 필요로한다.
2. 처음 40개의 스레드가 순차적으로 lock획득을 시도하며 40개의 스레드를 점유한다.
3. requires new로 새로운 트랜잭션을 시작하기 위해 새 connection이 필요하지만, 여유분이 없어 기다린다.(이때 데드락 상황)
4. 30초 대기후 timeout이 나서 커넥션들이 순차적으로 반환된다.
5. 이때 락을 획득 시도한 스레드(커넥션 점유중)가 반환되면
6. 나머지 39개의 락획득 시도하던 스레드들이 실행된다.
그래서 실제로 maximum pool size를 101개로 올리니 잘 실행되었습니다.
그런데 선생님은 40개로도 실행이 되어서.. 의문이 남습니다.
질문
저의 추측이 맞을까요..? 틀리다면 어디가 틀린걸까요.
왜 선생님은 40으로만으로도 된것인가요?
이런 이유에서 강의 중에 datasource를 분리하라 하신걸까요?
혹시 몰라 코드 첨부합니다.!
답변 2
0
jaeyun0507 님 안녕하세요!
테스트코드의 newFixedThreadPool 의 스레드 개수를 32개로 조절해보고 해주실 수 있으실까요?
지금 현재 코드로 보았을때는 100개의 스레드가 동시에 요청을 하여 커넥션 고갈이 일어나고 있는듯합니다.
0
안녕하세요, 인프런 AI 인턴입니다. jaeyun0507님!
질문해주신 내용을 바탕으로 NamedLock 테스트 실패 상황에서의 문제에 대해 분석해보겠습니다.
문제 분석
동작의 경우:
- 스레드가 한 번에 락을 획득하려 시도하지만,
maximum-pool-size의 제한으로 인해 충분한 연결을 확보하지 못하고 있음을 알 수 있습니다.
- 추측하신 대로
REQUIRES_NEW전파 속성으로 인해 새로운 트랜잭션이 시작되며, 추가적인 데이터베이스 커넥션이 필요하게 되어 연결 한계에 도달한 것으로 보입니다.
- 스레드가 한 번에 락을 획득하려 시도하지만,
데드락:
- 스레드들이 락을 획득하려 할 때, 기존의 트랜잭션이 완료되지 않아 커넥션이 반납되지 않는 상태에서 많은 수의 스레드가 동시에 작업을 시도하면서 데드락 상황이 발생할 수 있습니다.
- 스레드들이 락을 획득하려 할 때, 기존의 트랜잭션이 완료되지 않아 커넥션이 반납되지 않는 상태에서 많은 수의 스레드가 동시에 작업을 시도하면서 데드락 상황이 발생할 수 있습니다.
선생님의 환경:
- 서버나 데이터베이스 설정, 특히
maximum-pool-size와 관련 설정이 학생과 다른 환경에서 테스트됨에 따라 40으로도 실행이 되었을 가능성이 있습니다.
- 데이터베이스 연결과 관련된 설정이 커넥션 풀 외에도 여러 요인에 의해 영향을 받을 수 있으며, 이러한 설정 차이가 발생 원인이 될 수 있습니다.
- 서버나 데이터베이스 설정, 특히
해결 및 검토 방안
DataSource 분리:
비동기 작업이나 동시성 처리에서 세션 관리와 데이터베이스 연결의 분리 수준이 매우 중요합니다. 비효율적인 커넥션 사용을 방지하기 위해 강의 중 데이터 소스를 분리하는 방법을 논의했을 수 있습니다.유휴 연결 제공:
HikariCP와 같이 커넥션 풀 설정을 조정하여 여유 연결을 늘리는 것도 고려할 수 있습니다.트랜잭션 전파 속성 검토:
REQUIRES_NEW사용이 필수적인 케이스인지 검토하여 효율성을 재고해 보세요. 기존 트랜잭션의 활용이 가능한지 확인하는 것도 방법입니다.
이와 비슷한 문제에 대한 해결책을 제공한 기존의 질문과 답변을 아래에 안내합니다:
- NamedLock Test시 namedLockStockFacade.decrease()가 타지 않습니다 : 이 질문에서는 스레드에 의한 동시성 이슈와 관련된 해결책을 다룹니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
cp size를 40으로 thread 개수를 32로 했을 때는 잘 됩니다.
선생님께서는 강의에서 cp size를 40, 스레드 개수를 100으로 했음에도 테스트가 통과했는데, 이는 실행하는 컴퓨터의 cpu의 개수에 따라 결과가 달라져서 그런걸까요??
그리고 이렇게 커넥션 고갈 문제가 일어나서 named lock 사용시 lock용 데이터 소스와 비즈니스 로직용 데이터 소스를 분리하라고 하신것인가요??
감사합니다.