같은 PK로 조회시 쿼리가 2번 나가는 이유

대신 답변을 드려보자면 기본적으로 JpaRepository Interface의 target인 SimpleJpaRepository에서의 findById에서는 내부적으로 em.find를 통해서 조회를 합니다.그러나 위에서 보이는 JpaRepository에서의 Method Naming Query의 경우 em.find로 조회하는 것이 아닌 JPQL로 조회를 하기 때문에 Direct로 DB에 쿼리가 날라가게 됩니다대신 DB에서 Direct로 가져온 Entity가 이미 영속성 컨텍스트에서 관리되고 있다고 판단되면 Direct로 가져온 엔티티는 버리고 영속성 컨텍스트에서 이미 관리되고 있는 Entity를 응답하게 됩니다말씀하신 em.flush()의 경우에도 FlushOption자체를 건드리지 않은 기본 옵션의 경우 JPQL이 날라가기 전에 내부적으로 flush를 진행하게 됩니다메소드가 호출될때마다 clear & close를 하는것은 아닙니다

invalidSessionUrl

아 제가 chaining 위치를 잘못 잡아서 안보였었습니다. 혹시 다른 추가적인 질문이긴 한데 FilterSecurityInterceptor에서 "/user"자원으로 접근할 때 [Anonymous || RememberMe]사용자들에 대해서 먼저 인가예외로 갔다가 결국 Anonymous는 인증이 아예 되지 않은 사용자이므로 인증예외로 빠지고 RememberMe는 fullyAuthenticated가 아니라서 인증예외로 빠진다고 강의를 들으면서 이해하였는데그러면 이 경우에서 "/user"는 fullyAuthenticated()로 인가정보를 주게되면 RememberMe도 인증예외가 터지는데 만약에 그냥 authenticated()라고 주게되면 RememberMe 사용자는 인증예외없이 정상적으로 흐름이 넘어가는거 맞나요?

AnnotationAwareAspectJAutoProxyCreator 적용 오류

AppV1Config, AppV2Config내부에 v1, v2 빈 자체를 main에다가 빈 생성 후 실행을 시키면 정상적으로 돌아가는데 @Import({AppV1Config.class, AppV2Config.class})로 따로 불러와서 빈으로 등록하려면 오류가 발생하는데 이 원인을 잘 모르겠습니다...

회원 엔티티 분석

처음에는 사실 회원과 배송간의 관계가 1:N이 가능할거라고 생각해서 보니까 어차피 Order에 Member에 대한 정보가 있었고 만약 회원과 배송간의 1:N관계를 추가하게 된다면 [회원 -> 주문 / 주문 -> 배송 / 회원 -> 배송]이렇게 이행적 함수 종속 관계가 생긴다고 판단해서 정규화 과정에서 회원 -> 배송 부분을 없앴다고 생각하였는데 혹시 잘못된 부분이 있을까요?? 그리고 상품과 배송간의 N:M관계는 추후에 다시 생각해보니까 주문과 배송간에 1:1관계이고 주문에 어차피 "주문한 아이템"이 포함되어 있기 때문에 굳이 필요하지 않다고 판단이 들었습니다

다대일 연관관계 편의 메소드

그러면 이렇게 중복되는 instance가 컬렉션에 들어갈 위험이 있으면 repo에 insert하기 전에 예외를 터뜨려서 처리하는 방법은 괜찮은 방법인가요??