undo 메소드 작업중에서

제가 생각하는 light.on() 같이 Reciver의 메소드를 직접 호출하는 게 아닌 반대 성격의 command에게 위임하는 행위의 장점은 변경이 더 최소화 된다는 것 같습니다.light.on() API의 시그니처가 변경되면 기존 LightOffCommand의 undo 기능이LightOnCommand의 execute를 통해서 실행되기 때문에 LightOnCommand의 execute()만 변경하지만직접 on()을 호출하면 담당하는 Command와 반대 성격의 Command undo 부분 2가지 모두 변경해야 하기 때문입니다.

volatile 사용 이유에 대해서 여쭤보고 싶습니다!

이중 검사에서 synchroized 키워드로 원자성을 확보하고 이후에 접근하는 스레드들이 성능 이슈가 없게 하려고 맨 앞에 if(instance == null) 코드를 사용하는 건데 instance 변수에 대한 가시성이 확보되지 않아 이미 초기화되었는데도 synchroized 블록에 진입하여 성능 이슈가 생길까봐 volatile 키워드를 붙여 가시성을 확보한다. 저는 이렇게 이해했습니다

OncePerRequestFilter 질문

OncePerRequest가 아닌 일반 필터가 아닌 상황 request -> was -> 필터 -> 디스패처 서블릿 -> 컨트롤러 -> 서비스 에러 발생 throw Exception -> 이때 was는 error를 확인하고 error 페이지를 랜더링(forward)하기 위해서 다시 서블릿까지 보냄 결론 필터 2번 거침 was 까지 응답이 갔다가 다시 (일반)필터를 거치는 case 2가지 response.sendError / Uncaught Exception -------------------------------------------------- 강사님한테 질문 !!oncePerRequest가 한번만 필터링 되었는지 식별하는 로직이 복잡한듯한데 이렇게 복잡한 이유는 제가 설명한 에러 상황 이외에도 다른 케이스가 있을 거라고 추측을 합니다에러 상황이라고 하면 was는 attribute에 error를 넣어주니 간단하게 attribute를 확인해서 error 인지 확인하고 바로 넘기면 되니까요 다른 케이스를 하나 예시를 들어주실 수 있을까요?아님 제가 잘못 이해한 게 있을까요

Response 클래스

안녕하세요! 강의 재미있게 듣고 있습니다! 호돌맨님 답변중에 서비스에서 entity를 직접 Controller로 넘기지 않는 이유는Response로 변환할 때 뒤 늦은 entity의 참조를 방지하기 위해서 입니다.-> 이 이유는 연관관계가 있는 엔티티를 조회 시 지연로딩 때문이고 osiv를 false로 사용하기 때문일까요?

데이터 베이스 쿼리 실행 시점 관련 문의

AUTO_INCREMET 전략은 쓰지 지연 사용 안 하고 바로 INSERT 쿼리를 날려서 ID를 영속성 컨텍스트에 저장 SEQUENCE 전략은 INSERT 쿼리를 날리는 게 아니라 데이터베이스 시퀀스를 호출해서 ID를 영속성 컨텍스트에 저장하는 방식이어서 쓰기 지연 사용 근데 현재 강의에서는 AUTO 모드를 사용하는데 AUTO 모드는 AUTO_INCREMET, SEQUENCE, TABLE중에 하나를 각 DB 방언에 맞게 선택하는데H2 DB 같은 경우는 SEQUENCE를 사용하네요 로그를 보니까 실제로 SEQUENCE 호출 로그랑 DB에 시퀀스도 존재하구용 결론은 이번 케이스는 쓰기 지연을 사용하는 케이스입니다