16강 17강 간단 정리 이게 맞을까요 ?

도움이 되실지 모르겠지만 저도 제가 이해한 부분을 적어볼게요. 제 답변이 틀릴 수도 있다는 건 참고해주세요. ToOne 관계웬만하면 패치 조인이 좋다.조인을 해도 데이터가 증가하지 않고, 페이징 처리가 가능하기 때문이다.그냥 조인을 걸면 LAZY 로딩에 의해 N + 1 문제가 발생할 수 있으니, 패치 조인을 해서 성능 최적화를 한다.ToMany 관계패치 조인을 하면 LAZY와 관계없이 관련 데이터를 한번에 긁어오기 때문에 데이터 양이 정말 작다면 패치 조인을 해도 괜찮다.(쿼리가 한번만 발생하기 때문에)컬렉션 조회에서 페이징 기법은 웬만하면 사용하면 안된다. JPA 입장에서는 DB가 조회해준 데이터 중 어떤 부분을 페이징 처리해야할 지 구분하지 못하기 때문에 조회된 데이터 모두 메모리에 적재 후 One 입장에서 페이징을 수행한다.이때 OOM이 발생할 수 있다.컬렉션은 지연 로딩으로 설정한다.이후 default_batch_fetch_size 설정을 통해 설정한 size만큼 조회한다.IN 쿼리를 사용하기 때문에 데이터 수가 뻥튀기 되는 일대다 조인의 단점을 해결한다.(즉, PK를 기준으로 조건문을 사용하므로 데이터 증가 X, 조회 성능 업)중요한 건, 애플리케이션에서 LAZY 강제 초기화(LAZY 로딩 초기화를 위해 get 메서드 호출)를 하기 때문에 "LAZY 로딩 설정 + default_batch_fetch_size" 설정을 통해 IN 쿼리가 발생할 수 있다.즉, LAZY 강제 초기화를 하지 않으면 LAZY 초기화가 되지 않기 때문에(데이터 조회 X) IN 쿼리도 발생하지 않는다. 따라서 LAZY 강제 초기화를 하고 batch도 설정해야 한다. 이정도로 정리했습니다. 저도 답변을 달면서 정리가 되었네요. 혹시 틀린 점 있다면 피드백 부탁드립니다.

데이터베이스 테이블 생성 안됨

application-test.yml 파일이 존재했었네요..스프링의 기본 인메모리 디비를 사용해서 그런 것 같습니다.

데이터베이스 테이블 생성 안됨

다른 방법 다 해보았는데 해결이 안되네요..도와주시면 감사하겠습니다!

em.find 1차 캐시 SELECT 2번 발생

질문 드리다 보니 begin 메서드가 빠져 있어서 데이터베이스에 반영되지 않은 것을 확인했습니다..😅그래도 여전히 궁금한 부분은.. em.find()를 두 번 했을 때 영속성 컨텍스트에 저장되어 있는 값을 불러오니까 아예 select 문이 발생하지 않아야 할 것 같은데 왜 두번이 발생하게 되는지 잘 모르겠습니다. 그리고 이미 데이터베이스에 저장되어 있는 값(100L)을 여러 번 커밋해도 유니크 에러가 발생하지 않는 이유도 궁금해요

ExecutionContext 질문

강의보다가 한 가지 더 궁금한 점이 있어 여쭤봅니다.40:56초 쯤에 if 문에서 jobExecutionContext에서 이제 값을 조회할 수 있어서 if문이 걸리지 않는 것으로 알고 있는데요. 생각해보면 job을 실행할 때마다 jobExection이 새로 생성이 되고, jobExecutionContext는 jobExecution을 참조하는데 어떻게 해서 첫 번째에 시도했던 값을 파악하는 것인지 궁금합니다. 그렇게 되면 수행된 job이 많아질 수록 곁쳐지는 이름이 많아서 로직상 추후 원치 않은대로 수행될 가능성도 있을 것 같다는 생각인데 이 부분도 설명해 주실 수 있을까요?

ExecutionContext 질문

아 강의를 2번정도 다시 돌려봤는데 그제서야 보이네요..디버깅 하실 때 주소값이 다르네요!그런데 어떻게 같은 타입인데 jobExecution은 공유가 가능하고, stepExecution은 공유가 불가능한지.. 궁금합니다!제가 ExecutionContext 클래스를 봤을 땐 인터페이스인가 해서 봤더니 그냥 클래스더라구요