TIL-220622

🛎 하루 일과

10:00 ~ 10:30 데일리 스크럼
10:30 ~ 12:30 Issue Tracker 프로젝트
14:30 ~ 15:40 Dion 특강
16:00 ~ 18:10 Issue Tracker 프로젝트

 

🤝 Issue Tracker 8일차

오늘도 산토리와 작업을 이어나갔다.
오늘은 오전에는 네비게이터, 오후에는 드라이버로 작업을 진행했다. 중간에는 디온의 특강이 있었고, 생각을 정리할 수 있는 유익한 시간이었다.

📝 작업

• 유저 회원가입 시 비밀번호 암호화
  • jbcrypt 라이브러리 사용
• access 토큰 갱신하는 로직 작성

💭 고민사항

영속성 컨텍스트의 단위는?

현재 서비스에서는 jwt 토큰을 사용해서 사용자 인증을 구현했다.
jwt토큰에 유저 식별 id를 claim 값으로 넣고 있으며 토큰 검증 후 userId를 사용해서 user 객체를 조회해서 인터셉터에서 컨트롤러에게 넘겨준다.

//AuthInterceptor의 preHandle 메서드의 일부

...

jwtProvider.verify(token);

User user = service.findById(userId);

request.setAttribute("user", user);

return true;

이와 같은 방식으로 구현한 이유는 대부분의 요청에서 사용자의 정보를 사용하기 때문에 유저를 조회하는 로직의 중복을 줄이기 위함이다.

하지만 이렇게 했을 경우 문제가 발생했다.

컨트롤러에 넘겨준 User 객체는 영속성 컨텍스트에서 관리를 해주지 않는다.
즉, 엔티티 객체의 값이 변경되도 더티체킹이 발생하지 않고 DB에도 변경사항을 적용하는 쿼리가 날아가지 않는다.

단순히 인터셉터에서 하나의 트랜잭션이 끝났으니 당연히 안된다고 생각했지만, 호기심에 인터셉터에서는 userId만 세팅해주고 어노테이션을 처리해주는 ArgumentResolver에서 유저를 조회 후 반환하도록 코드를 변경해보니 컨트롤러로 넘어온 해당 객체를 영속성 컨텍스트에서 관리해주는것을 발견했다.

//AuthArgumentResolver의 resolveArgument메서드

  public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {

      HttpServletRequest request = (HttpServletRequest) webRequest.getNativeRequest();

      String authorization =(String) request.getAttribute("authorization");

      return authService.findUser(authorization);
  }

어떤 차이가 있는지 모르겠어서 모각코방에 계시던 로치에게 질문해본 결과

• 인터셉터에서 조회해오는 경우는 저기서 트랜잭션이 닫히고 이후에 다시 열리는 구조라서 그런것 같고, ArgumentResolver에서 조회하는 경우에는 resolver -> controller -> service 까지 트랜잭션이 연결되는 구조 같다.
• 일단 트랜잭션은 서비스 내에서만 열고 닫는게 좋다!
• 중복을 제거하기 위해서 현재 구조로 만든건 괜찮다! 나중에 스프링 시큐리티 사용하면 굳이 인터셉터에서 조회 안해도 해결이 된다
• pk로 객체를 조회해와야 더티체킹이 된다!

라는 답변을 받았다.

추가적으로 학습해볼 링크까지!

OSIV와 성능 최적화

일단 추측을 해보자면, 인터셉터에서 조회한 user 객체가 request.setAttribute()를 통해 세팅되는 시점에 트랜잭션이 닫히는 것 같다. 반면 ArgumentResovler에서 조회하는 경우는 조회한 객체를 바로 반환해주기 때문에 해당 트랜잭션이 유지가 되고 있는건가.. 라고 생각을 했는데 아직 트랜잭션과 영속성 컨텍스트에 대한 이해가 부족해서 추가 학습이 필요할 것 같다.