프로젝트가 더 낮은 버전에서만 실행되는 이유?

안녕하세요. yoon6669님스프링 부트 스타터를 통해서 프로젝트를 설정했다면 보통 문제없이 작동해야 하는데요.저희가 문제를 확인해볼 수 있도록 프로젝트 전체 파일을 압축해서 전달해주시겠어요?(참고로 자바 17로 진행하셔도 괜찮습니다.)실제 동작하는 전체 프로젝트를ZIP파일로 압축해서 구글 드라이브로 공유해서 링크를 남겨주세요.구글 드라이브 업로드 방법은 다음을 참고해주세요.https://bit.ly/3fX6ygx 주의: 업로드시 링크에 있는 권한 문제 꼭 확인해주세요추가로 다음 내용도 코멘트 부탁드립니다.1. 문제 영역을 실행할 수 있는 방법2. 문제가 어떻게 나타나는지에 대한 상세한 설명 (오류 화면, 오류 로그 포함) 링크: 공식 서포터즈링크: 자주하는 질문감사합니다.

데몬스레드 파트 첫 번째 예제

안녕하세요. 자바재밌당님우선 다음 링크에 남겨둔 것 처럼 예외 처리에 대한 복습이 필요합니다.https://inf.run/X1QCt그리고 이번 장에 있는 체크 예외 재정의 부분을 복습해주세요.둘의 복습이 되셨다면 다음 설명을 참고해주세요 🙂 여기서 체크 오류를 잡아서 끝내도 괜찮습니다. 다만 Runnable의 구현체는 체크 예외를 던질 수 없습니다. 여기서는 간단한 예제이기 때문에 예외를 던지도록 했습니다. 이렇게 하면 예외가 발생했을 때 해당 예외의 추적 내용이 콘솔에 출력되기 때문에 간단하고 편리하게 오류 내용을 확인할 수 있습니다.이후에 설명하지만 자바에서는 모든 스레드(데몬이 아닌)가 종료되어야 프로그램이 종료됩니다. 따라서 이 스레드 하나만 종료되어도 괜찮습니다.감사합니다.

멀티스레드의 예외 처리

안녕하세요. 자바재밌당님다음 링크에 답변 남겨두었습니다.https://inf.run/X1QCt감사합니다.

인터럽트, 체크 예외 catch 재질문

안녕하세요. 자바재밌당님다음 링크에 답변 남겨두었습니다.https://inf.run/X1QCt감사합니다.

쓰기지연 vs batch_size 네트워크 전송 횟수 질문

안녕하세요. jayjoy05님같은 타입의 엔티티를 영속성 컨텍스트에 3번 저장했다고 가정하겠습니다.해당 batch_size 설정이 없다면 flush() 시점에 3번의 네트워크 호출이 발생합니다.batch_size를 3으로 설정하게 되면 1번의 네트워크 호출이 발생합니다.감사합니다.

순수 라이브러리 사용하기 2 - memory-v1

한현진님 공유 감사합니다 🙂

client.disconnect()를 if 문안에 넣어서 오류발생하더라도 disconnect 메서드가 호출되고 return 되게 해도 되나요?

안녕하세요. jsh4059님가능은 해 보이지만, disconnect 를 호출하는 부분이 여러곳에 중복되는 문제가 있어 보이네요 🙂감사합니다.

인터럽트, 체크예외 catch 질문

안녕하세요. 자바재밌당님우선 Thread.sleep(3000)을 호출했지만 해당 시점에 예외가 발생한 것이 아닙니다.따라서 3초간 대기한 이후에 다음 로직이 정상 수행됩니다.Thread.sleep(3000)은 체크 예외를 던집니다. 체크 예외의 경우 반드시 잡아야 하도록 코드를 강제하기 때문에 catch로 해당 예외를 잡도록 코드를 작성한 것입니다.만약 Thread.sleep(3000)을 호출하는 동안 예외가 발생했다면 해당 예외를 잡겠지만 그게 아니라면 다음 로직이 정상 수행됩니다. 여기서는 정상 수행되었습니다.예외 처리에 대한 부분을 다시 한번 정리하고 복습하는 것이 필요해보입니다. 자바 중급 1편 -> 9. 예외 처리1, 10. 예외 처리2 부분을 꼭 다시 공부하고 넘어와주세요.감사합니다.

@OneToOne, @OneToMany만 가능한 이유

안녕하세요. 오리쉐리님JPA에서 고아 객체(Orphan Removal) 기능이 @OneToOne과 @OneToMany 관계에서만 사용 가능한 이유는 다음과 같습니다:소유권(Ownership)의 명확성:@OneToOne과 @OneToMany 관계에서는 '소유하는 측'과 '소유되는 측'이 명확합니다. 부모 엔티티가 자식 엔티티를 명확하게 소유합니다.따라서 부모 엔티티에서 자식 엔티티의 참조를 제거했을 때, 해당 자식이 '고아'가 되었다고 판단하기 용이합니다.@ManyToMany에서의 문제점:다대다 관계에서는 양쪽 엔티티 모두 컬렉션으로 서로를 참조합니다.한 쪽에서 참조를 제거했다고 해서 그 객체가 진정한 '고아'라고 할 수 없습니다. 다른 엔티티에서 여전히 참조할 수 있기 때문입니다.이런 상황에서 고아 객체 제거를 허용하면 예상치 못한 데이터 손실이 발생할 수 있습니다.@ManyToOne에서의 문제점:다대일 관계에서는 '다(Many)' 쪽의 여러 엔티티가 '일(One)' 쪽의 하나의 엔티티를 참조합니다.한 엔티티가 참조를 끊었다고 해서 참조 대상이 고아가 되는 것이 아닙니다. 다른 엔티티들이 여전히 참조하고 있을 수 있습니다.고아 객체 제거는 부모-자식 관계가 명확하고, 자식 엔티티의 생명주기가 부모 엔티티에 완전히 종속된 경우에만 안전하게 사용할 수 있으므로 @OneToOne과 @OneToMany에서만 허용됩니다.감사합니다.

자동리소스등록?

안녕하세요. 임다정님다음 내용을 참고해주세요.스프링 DB 1편4. 스프링과 문제 해결 - 트랜잭션 -> 스프링 부트의 자동 리소스 등록감사합니다.