영속성 컨텍스트 및 캐시 관련하여 질문이 있습니다.

자바 ORM 표준 JPA 프로그래밍 - 기본편

작성

영속성 컨텍스트는 서버 인스턴스 내부의 트랜잭션 기준말고 별도의 추가 기준이 있나요?

현재 진행 중인 프로젝트에서 프론트는 리액트로 진행 중인데 리액트로 호출하면 수정하기 이전의 쿼리로 조회한 데이터가 여전히 조회됩니다.

그런데 해당 페이지에서 개발자 도구를 켜서 fetch 메소드로 조회하거나 포스트맨으로 조회하면 새로운 버전의 쿼리로 조회한 데이터가 조회됩니다.

혹시 결과가 다른 이유가 있을까요?

그리고 서버가 재시작됬는데도 데이터가 똑같은 이유가 있을까요?

배포는 도커랑 깃랩 러너로 하고 있습니다.

답변 1

안녕하세요. 그냥곰님, 공식 서포터즈 y2gcoder입니다.

제가 그냥곰님의 상황을 정확하게 이해한 것인지는 모르겠으나, 이미 API로 응답을 받았다면 보통은 영속성 컨텍스트 를 떠난 상태입니다!

리액트를 사용하고 계신다면 OSIV 문제도 아닐 것으로 생각되는데, 브라우저 단의 캐시를 한번 확인해보시겠습니까?

감사합니다.

질문자

안녕하세요 답변 감사합니다

브라우저의 캐시를 지워도 이전 데이터가 남아있어서 추가로 문의 드릴게 있는데요.

현재 해당 API에 대해서 HttpServletResponse의 addHeader 메소드를 통해

Cache-Control: max-age=60을 설정하기도 했고,

혹시 몰라서 쿼리를 로그로 찍어봤는데도 수정한 버전의 쿼리가 나오는데

그렇다면 이전 데이터를 어디에서 가져오는 건지 정확히 알 수 있는 방법이 있을까요?

+ 같은 API를 앱단에서도 사용하고 있는데 동일한 결과가 나오고 있습니다.

말씀해주신 상황만 가지고는 알기가 어렵습니다!

디버깅해보셨을 것 같은데 디버깅해보셨을 때 컨트롤러 응답 바로 전의 데이터도 수정한 후의 데이터라면, 백엔드 프로젝트의 문제가 아닐 수도 있습니다.

전체적으로 요청부터 응답까지 디버깅을 한번 해보시겠습니까?

추가로 수정이라는 것이 서비스 로직에서의 데이터 수정이 아니라 코드의 수정 이라면

빌드 후 배포가 제대로 되지 않았을 수도 있습니다 🙂

도커 컨테이너가 이전 버전의 jar를 그대로 사용하고 있기 때문 일 수 있습니다!

질문자

다행히 해결했습니다.

알고보니 JPA 캐시 문제는 아니었고

TypedQuery에 설정할 값을 가공하는 도중 생긴 문제였습니다.

파라미터 개수가 많고, API 호출 방식이 워낙 다양하다 보니 발생한 문제였습니다.

디버깅을 한다고 했는데도 겉핥기로만 한게 되버려서 부끄럽네요.

덕분에 제 스스로 부족한 점들을 많이 깨닫게 되었습니다.

친절한 답변 감사합니다.

해결하셔서 다행입니다 🙂
파이팅입니다!

인프런 커뮤니티 질문&답변