영속성 컨텍스트 1차캐시 질문

안녕하세요 영욱님! 🙂 정말 기가 막힌 포인트를 찾아내셨군요...! 👍 결론부터 빠르게 말씀드리면, 이것은 OSIV 라는 옵션 때문입니다. Open-Session-In-View 옵션은 기본적으로 true로 설정되어 있는데spring: jpa: open-in-view: false를 이용해 false로 만들 수 있고요 실무에서 권장되는 값은 false 입니다. 그럼 이제 OSIV 옵션이 무엇인지 설명을 드리면,만약 이 값이 true로 설정되어 있다면, 트랜잭션이 열러 영속성 컨텍스트가 한 번 로딩되면, 해당 요청이 완전히 종료될 때까지 영속성 컨텍스트를 유지하게됩니다.때문에 위 경우는 처음 로딩된 findById() 에서 Repository 내부에 있는 트랜잭션 실행 -> OSIV 설정에 의해 영속성 컨텍스트가 유지되어 버림 -> Service 종료시점까지 (심지어 Controller를 완전히 벗어나 요청이 끝날 때까지) 영속성 컨텍스트가 남아 있게 됩니다. 이런 설정이 존재하는 이유는 과거의 "템플릿 엔진"을 사용했기 때문인데요요즘에는 react.js 혹은 next.js와 같은 FE 영역과 RESTful API BE 영역이 완전히 구분되지만, 옛날에는 서버가 직접 HTML을 브라우저에 반환하는 기법을 사용했습니다. 그리고 HTML을 사용자마다 다르게 보여주려면, 안녕하세요 ??? 님 처럼 ??? 이란 빈 칸을 뚫어두고 DB에서 조회해온 값을 여기에 넣어주게 되었죠.이때 DB에서 조회해온 값 (= Service와 Repository를 거쳐 받아온 값) 을 템플릿 엔진에서 조금 더 적극적으로 사용하기 위한 (= 빈칸에서 Entity를 이리저리 사용하기 위한) 옵션이 OSIV 였습니다. 현재 실무에서 OSIV를 false로 권장하는 이유는, 대부분 REST API를 만들기 때문에 OSIV 처럼 암시적으로 영속성 컨텍스트가 오래 유지되며 생기는 문제들을 원천 차단하기 위해서입니다. OSIV를 잘못 사용하게 되면 Controller에서 Entity에 넣은 값이 dirty check 등으로 저장되어 버릴 수도 있고, 영속성 컨텍스트를 오래 유지하며 시스템 자원이 낭비될 수도 있기 때문이죠. 이런 부분은 첫 서버를 배우는데 함께 설명드리기에는 어려운 내용이라 이번 강의에서는 제외되어 있습니다. 🙂 열심히 들어 주셔서 감사합니다. 또 궁금한 점 편하게 질문 올려주세요! 감사합니다. 🙇

ddl-auto 관련 질문.

안녕하세요 영욱님! 🙂 좋은 질문 감사드립니다. 결론부터 말씀드리면 validate 과정에서는 JPA에 있는 column을 기준으로 DB에 해당 column이 존재하는지를 확인하고 있습니다. 때문에 꼭 nullable 필드가 아니더라도 DB에 column이 더 많다면 검증 과정에서 애플리케이션 부팅 과정을 중단하지 않을겁니다. 또한 Column 에 들어가는 속성 값 중 type과 같이 조금 중요한(?) 일부 설정은 함께 검증해주는 것으로 알고 있는데 그 외 설정들은 검증하지 않는 경우가 있습니다.실제 검증 로직은 AbstractSchemaValidator 에서 확인하실 수 있는데요링크 : https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core/src/main/java/org/hibernate/tool/schema/internal/AbstractSchemaValidator.java#L126(table.getColumns 에서 가져오는 column이 JPA Entity의 column입니다. 물리 테이블을 기준으로 비교하고 있지 않죠.) 저는 개인적으로 validate 를 사용하지 않고 직접 DDL 변경을 챙겨주는 편을 선호합니다. 🙂그 이유는 확인해보신 것처럼 validate 자체가 완벽하지 않을 뿐더러 DB schema를 완벽하게 관려하려면 (비록 MySQL 8.0부터는 유료이지만) flyway라는 툴이 조금 더 나을 수 있기 때문이죠. flyway보다 직접 DDL 변경을 챙겨주는 것을 선호하는 이유는 flyway를 사용함으로써 flyway 규칙을 따라야만 해서 오히려 유연함이 떨어지는 경우가 종종 있고, 유료 솔루션을 사용하는 것에 대해 조직 단위 설득이 어려운 이유도 있습니다. 이렇게 직접 옵션을 꼼꼼하게 확인해보시다니 대단하시네요~! 😊또 궁금한 점 있으시면 편하게 질문 남겨주세요. 감사합니다. 🙇

[28000][1045] Access denied for user 'root'@'localhost' (using password: YES)

안녕하세요! kangaroo125님! 🙂 해당 오류는 일반적으로 비밀번호가 틀렸다는 오류입니다. Access denied for user 'root' 혹시 비밀번호를 올바르게 입력하셨는지 확인해보시면 좋을 것 같습니다.감사합니다. 🙇

GitHub에 application설정 내용 push

안녕하세요 재성님! 질문 주셔서 감사합니다.결론부터 말쓰드리면, "gitignore을 통해서 push하지 않도록 하지 않는" 이상 다른 방법은 없습니다! 🥲 그래서 비밀번호를 설정할 때 1234 같은 단순한 비밀번호로 설정하라고 말씀 드렸던 거에요!! 실무에서는 보통application.yml 같은 곳에도 비밀번호를 두지 않고 AWS SecretsManager 같은 외부 솔루션을 통해 아예 비밀번호 자체를 모르게끔 처리하는 편입니다. 감사합니다. 🙇

간단 질문.. join() vs delay()

안녕하세요 보키님! 🙂 질문 주셔서 감사합니다.아래 1번, 2번 방법 중에 어떤 차이가 있고, 코루틴을 현업에서 쓸 때는 어떤 방법으로 보통 사용하게되나요?오...! AI 인턴의 사용이 매우 정확하군요- join()을 사용하는 것이 명확하고 안정적입니다. 원하는 코루틴이 완료될 때까지 기다린다는 의미를 명확히 전달하기 때문입니다.- delay()는 명시적인 요구사항에 따라 T를 기다리고 싶을 때 사용되지만, 보통 정확한 완료를 보장하지 않기 때문에 join()을 대체하는 용도로 사용되지는 않습니다.delay() 는 임의의 시간을 멈추는 것이기 때문에 join() 을 대체하는 용도로는 사용되지 않습니다. 그리고 강의를 아직 다 보지는 않았는데.. RxJava, WebFlux, Virutal Thread, Coroutine 등을 어떤 영역에서 활용하는지 궁금합니다Network, File I/O, DB CRUD, External API call, etc...본 강의는 코루틴 강의이기 때문에 RxJava, Webflux, 가상 스레드 등에 대해서는 설명하고 있지 않습니다. 그렇지만 여기서 간단히 설명드리면 RxJava, Coroutine은 non-blocking 작업을 처리하기 위한 코드 스타일이고요~ WebFlux는 non-blocking을 활용할 수 있도록 만들어진 framework, Virtual Thred는 blocking I/O를 non-blocking 하게 처리할 수 있도록 해주는 기법 입니다.결국 넷 모두 non-blocking I/O를 핸들링 하기 위한 기술이기에 I/O가 발생하는 곳이라면 어디든 적용 가능합니다. 🙂 그리고 음.. 2022년도쯤에는 비동기트랜잭션이 하이버네이트쪽에서 잘 지원 안해줘서 r2dbc를 사용하다가 취소한 곳이 있다고도 얼핏 들은것같은데 현재는 어떤지 위에 활용처 질문과 함께 알려주시면 감사하겠습니다!우선 Hibernate 과 R2dbc는 서로 약간의 대체제 관계입니다. Hibernate에서 non-blocking이 잘 지원되지 않기 때문에 R2dbc를 사용해야 하는 것이고, 지금은 Hibernate도 non-blocking에 대한 지원이 확대 되었다고는 하나 여전히 non-blocking 영역에서는 R2dbc가 더 많이 사용되는 편입니다.답변이 도움이 되었으면 좋겠습니다. 감사합니다. 🙇