해결된 질문
작성
·
423
·
수정됨
0
안녕하세요. 선생님.
선생님 강의로 많이 배우고 있네요.
UrlFilterInvocationSecurityMetadataSource 를 직접 구현하여 DB와 연동하는 것을 보여주셨는데.
이 클래스에 Resouce 인가 설정을 위한 클래스의 멤버 변수로 LinkedHashMap<RequestMatcher, List<ConfigAttribute>> requestMap 을 사용하네요.
만약 DB에 Resource, Role 인가 설정 변경 시 reload()가 불렸을 때 DB에서 모두 가져와 requestMap 에 put 하는데 이것이 multi thread 에 safe 한지요?
만약 thread에 safe 하지 않다면 좋은 방법이 있는지요? lock을 쓰기에는 read 요청이 많아 부담스러울 것 같다는 느낌이 있네요.
강의에서 Role 추가 시 실시간 설정 반영은 하지 않았지만 RoleHierarchy 또한 마찬가지 인 것 같아요.
운영 시 거의 변경이 안되기 때문에 그냥 놔두는게 가장 좋은 방법인지? 선생님의 의견을 알고 싶어요.
감사합니다.
답변 2
1
네
reload() 를 호출하는 것은 일반 사용자가 아니라 관리자가 하기 때문에 동시성의 문제가 발생할 확률이 극히 낮거나 무방하다고 봐도 됩니다.
물론 여러 명의 관리자가 동시에 reload() 를 호출하는 경우 동시성 문제에 노출될 수 있지만 그렇게 염려할 정도는 아니라 봅니다
그리고 reload() 는 디비에 있는 값을 다시 로드해서 세팅하는 것이기 때문에 여러명의 관리자가 각기 다른 값을 디비에 저장할 경우 가장 마지막에 저장한 값이 reload() 에 반영될 것입니다.
이것은 당연한 결과일 수 있습니다.
결론적으로는 스레드에 세이프한 코드는 아니지만 동시성 문제가 발생할 확률은 거의 없고 디비의 값이 반영되는 구조라 보시면 됩니다.
0
안녕하세요 김현진 님, 인프런 AI 인턴이에요.
질문하신 내용은 멀티스레드 환경에서 안전성에 관한 것인데요. 일반적으로 LinkedHashMap은 스레드에 안전하지 않은 자료구조입니다. 많은 스레드에서 동시에 접근할 경우 예측할 수 없는 결과가 발생할 수 있습니다.
스프링 시큐리티에서는 이에 대한 고려를 해서 내부적으로 동기화를 처리하고 있기 때문에 멀티스레드 환경에서 안전하게 사용할 수 있습니다. 따라서 UrlFilterInvocationSecurityMetadataSource의 requestMap을 여러 스레드에서 동시에 접근해도 안전하게 동작할 것입니다.
Role 추가 또는 변경 시의 실시간 설정 반영에 대해서는 환경에 따라 다를 수 있습니다. 만약 거의 변경이 없는 경우라면 그냥 놔두는 것이 가장 간단하고 안정적인 방법일 수 있습니다. 하지만 변경이 자주 일어나는 경우라면 실시간으로 반영되는 것이 중요할 수 있으므로 그에 맞게 구현하는 것이 좋습니다.
추가적인 의견이 필요하시다면 스프링 시큐리티 공식 문서나 관련 포럼을 참고하시면 도움이 될 것입니다. 감사합니다.
감사합니다.