job launcher관련 질문 있습니다.

job 이 빈이니까 job 빈 객체의 이름으로 구분하여 사용하시면 되지 않을까 합니다 가령 private final JobLauncher jobLauncher; private final Job jobA; private final Job jobB; private final Job jobC; @Autowired public BatchController(JobLauncher jobLauncher, Job jobA, Job jobB, Job jobC) { this.jobLauncher = jobLauncher; this.jobA = jobA; this.jobB = jobB; this.jobC = jobC; } 이런 식으로 말이죠

slave 청크의 실패 횟수에 따라 나머지 청크를 중지시키는 방법이 있을까요?

네 이 부분은 리스너를 통한 커스텀 구현도 방법은 되겠으나 스프링배치의 구조적인 방식과는 조금 거리가 멀고 강제종요로 인해 리소스 해제나 트랜잭션 처리에도 이슈가 될 수 있습니다 보통 스텝이 실패할 경우 skip 이나 retry 를 사용하여 오류를 관리합니다 예를 들어 다음과 같은 경우를 생각해 볼 수 있습니다 return new StepBuilder("apiStep", jobRepository) . chunk(CHUNK_SIZE, transactionManager) .reader(helloReader(null)) .processor(helloVO -> { LocalDate date = helloVO.getDate(); if(date.getDayOfMonth() == 10){ throw new IllegalStateException("!! " + helloVO); } return helloVO.toEntity(); }) .writer(v -> log.info("write = {}", v)) .faultTolerant() .skipPolicy(new LimitCheckingItemSkipPolicy(MAX_FAILURES, IllegalStateException.class)) .listener(skipListener) .build(); 즉 최대실패갯수에 도달할 경우 어떤 처리를 하도록 하는거죠 위 코드는 하나의 예시라고 이해하시면 됩니다

chunk 처리 기반에서 cursor 방식과 메모리 사용

사실 스프링 배치에서는 청크 사이즈만큼 트랜잭션이 일어나기 때문에 커서 방식에서 크게 메모리 사용량이 늘어나지는 않습니다 강의에서 설명한 것은 일반적인 커서방식을 의미하는 것으로서 스트리밍 방식으로 계속 데이터를 로드하는 경우 메모리에 쌓이게 되는 경우를 말합니다 그에 반해 페이징은 페이지크기만큼만 로드하기 때문에 메모리 사용량이 덜하다는 의미라 볼 수 있습니다 결론은 커서든 페이징이든 어느 정도의 fetchsize 로 메모리에 데이터를 로드할 것인가에 따라 메모리 사용량이 달라진다고 보시면 됩니다 스프링 배치는 그런 관점에서 청크사이즈만큼 트랜잭션이 이루어지므로 대용량 데이터 처리에 최적화 된 기술을 제공하고 있다고 보시면 됩니다

실전강의 질문 (Rest 인증 필터 구현)

아래 답변을 참고하시면 되는데 만약 설정을 하지 않으면 그건 시큐리티 내부적으로 또 한번의 객체를 생성할려고 시도하게 되고 결국 오류를 발생하게 됩니다 강의에서 설명하는 것은 우리가 직접 AuthenticationManager 를 얻기 위한 작업을 하고 있는데 원래는 시큐리티가 내부적으로 진행하는 작업입니다 그래서 중복실행을 방지하기 위해 객체를 설정하게 되면 시큐리티가 객체릴 생성하기 위한 작업을 하지 않습니다 이 부분은 아주 중요한 부분은 아니니 참고 정도로만 아시면 됩니다

스프링 부트 버전

네 괜찮을 것 같습니다^^