형이 이 강의에서 말하는거보면 여러 방면으로 JpaPagingItemReader에 안 좋은점에 대해서만 말하는거 같애 (실시간으로 데이터 추가/삭제로 인한 데이터 누락/중복의 가능성, 페이지별로 트랜잭션 커밋, 플러시 하는 동작으로 인한 사이드 이펙트, 오프셋 기반의 페이징에 의한 성능저하 등등) 그럼 JpaPagingItemReader는 JpaCursorItemReader와 비교하면 쓸 이유가 없는 놈인거야..?? 지피티 말로는 JpaPagingItemReader가 스레드 세이프한 점, 그리고 커서를 장기간 유지하는 것에 대한 부담이 없다는 점에서 더 나은점도 있다고 하는데 이건 와닿지가 않고 잘 모르겟어
이거 6버전으로 읽고 있다가 문득 이상해서 질문남긴다. RunIdIncrementer <- 이거 지금 5랑 6랑 동작.. 완전 다른거 같은데 맞냐..? (완전 다르다기 보다, 스프링 배치 리드의 이슈에서는 너네가 잘못 쓰고 있던거다 라고 하긴하던데) 전에는 같은 파라미터로 재시작할때도 사용가능했는데, 이제는 이거 안바꾸고 버전업하면 "하위고과" 확정이다.
아직은 어색하고 서먹서먹하니 존댓말로 질문드립니다. 인프피니까 이해좀.. 1장. 작전1: 바이너리 초이스 - 스프링 배치의 두 가지 스텝 유형 요걸 지금 읽고 있는데 중간에 이런 내용이 있습니다. [시스템 주의] 예시와 같이 ResourcelessTransactionManager 인스턴스를 직접 생성해 tasklet() 메서드에 전달해도 되지만 애플리케이션 내의 여러 스텝에서 재사용할 수 있도록 별도의 Bean으로 정의하고 싶을 수도 있다. 그러나 PlatformTransactionManager 빈을 직접 정의할 땐 주의가 필요하다. 뭔가 문장이 좀 어색한데 처음엔 ResourcelessTransactionManager인스턴스를 Bean으로 정의하고 싶을 수 있다고 하시고는 갑자기 PlatformTransactionManager 빈을 직접 정의할 땐 주의가 필요하다고 하셨습니다. 이게 말 그대로 PlatformTransactionManager 빈을 직접 정의할 때 주의 하라는 뜻인건지, 아니면 ResourcelessTransactionManager 빈을 직접 정의할 때 주의 하라는 뜻인건지, 아니면 둘 다 빈을 집적 정의할 때 주의 하라는 뜻인지 조금 헷갈립니당 뒤에 따라오는 문장들을 읽어보면 아마도 PlatformTransactionManager 빈을 직접 정의할 때 주의하라는 말 같은데 그럼 ResourcelessTransactionManager 빈을 직접 정의 할 때의 주의사항은 없나용?
형 질문있어. 페이징 기반 ItemReader 에서는 예제와 같이 ORDER BY 를 추가해야 한다. ORDER BY 가 없으면 매 페이지를 읽을 때마다 데이터의 순서가 보장되지 않아 일부 데이터가 누락되거나 중복될 수 있다. 라고 했잖아. 이 말은 곧 " JpaCursorItemReader 는 ORDER BY를 추가하지 않아도 괜찮다"로 들리는데 맞아? GPT는 아니라고 하거든. cursor 기반도 마찬가지로 ORDER BY가 없으면 재실행마다 DB에 정렬 순서를 위임하는데, DB는 쿼리 플랜이 변경되는 등 여러 원인들에 의해 실행마다 달라질 수 있대. 뭐가 맞아?
단일 실행이 보장되는 이유로 Db를 통해서 값을 가져오고 있으며 db에서 동시성을 방어해주고 있기 때문이라고 해주셨는데요. FindRunningJobExecutions 는 단순 select문이 아니고 내부적으로 비관적 락으로 동시 접근을 막아주는 구조인가요? 저는 여러 파드인 상황에서는 보여주신 코드가 동시성 이슈로 인해 주어진 잡이 한 번만 실행된다는 것을 보장하기 힘들 것 같다고 생각했습니다. 이외에도 여러 파드인 상황이라면 실무에서 어떤 요소를 고려하는지 궁금합니다. 학습 내용에선 currentimestamp를 잡 파라미터에 넣어서 매번 새로운 잡 인스턴스로 취급/실행하는 형태를 보여주셨는데, 이로인해 멀티파드 환경에서 특정 잡의 중복 실행 방지 혹은 특정 잡 파라미터 구성에서의 중복 실행 방지에 대한 요건 구현 시 영향도/고려 사항이 있는지 여부와 아니면 currentimestamp 잡 파라미터를 실무에서 빼기도 하는지 궁금합니다 운영 시 중복 실행 문제 및 잡 재시도에 대해 고민하다 나온 질문입니다. 혹시 애초에 대부분의 배치 잡과 스탭 로직을 멱등하게 동작하도록 설계 및 코드 작성을 해야하는 걸까요?
형 나 지금 너무 재밌어서 잘 따라하던중 별거 아닌거에서 막혀서 좀 힘들어 형이 알려준 json 파라미터 넘기는 방법으로 해도 안되고 gpt 찾아서 진행 한거도 다 안돼는데 윈도우 환경에서 좀 힘든걸까 ?? 다른 수강생분이 올려준거도 봤는데 답변에 달아준 방법도 동작하지 않아 @Bean public JsonJobParametersConverter jobParametersConverter() { return new JsonJobParametersConverter(); } @Bean @StepScope public Tasklet terminatorTasklet( @Value("#{jobParameters['infiltrationTargets']}") String infiltrationTargets ) { return (contribution, chunkContext) -> { String[] targets = infiltrationTargets.split(","); log.info("⚡ 침투 작전 개시"); log.info("첫 번째 타겟: {} 침투 시작", targets[0]); log.info("마지막 타겟: {} 에서 집결", targets[1]); log.info("🎯 임무 전달 완료"); return RepeatStatus.FINISHED; }; }
안녕하세요. 잡이 어떻게 스텝에서 사용하는 컨텍스트 값까지 가지고 있는지 잘 이해가 되지 않아 질문드립니다. 분명 JobExecutionContext 에 넣은 것이 아니라 StepExecutionContext 에 값을 저장했는데, 확인해보니 JobExecutionContext 에도 동일하게 저장된 것처럼 보여서 헷갈렸습니다. 제가 이해한 바로는 JobExecutionContext 와 StepExecutionContext 는 서로 다른 영역이고, JobExecutionContext 는 step 간 공유용, StepExecutionContext 는 해당 step 전용으로 알고 있습니다. 그런데 왜 StepExecutionContext 에 넣은 값이 JobExecutionContext 에도 같은 형태로 보이는지 잘 모르겠습니다.
형 ... @Bean public Step threatAnalysisStep( JpaPagingItemReader<Human> humanThreatDataReader, ItemProcessor<Human, TargetPriorityResult> threatAnalysisProcessor, FlatFileItemWriter<TargetPriorityResult> targetListWriter ) { return new StepBuilder("threatAnalysisStep") .<Human, TargetPriorityResult>chunk(10, transactionManager) .reader(humanThreatDataReader) .processor(threatAnalysisProcessor) .writer(targetListWriter) .taskExecutor(taskExecutor()) // deprecated 되어서 안씀 // .throttleLimit() .build(); } ... 에서 .throttleLimit() 부분이 5 이후로 deprecated 된다고 명시되어 있어. 관심사 분리로 인해서 taskExecutor 정의 부분에서 설정하라고 권장하는 것을 확인했거든. 현재 강의가 사실상 Spring Batch 5.x 까지의 기본 내용과 원리를 살펴봤잖아 ? 그렇다 하더라도 혼란을 줄 수 있기 때문에 해당 부분은 삭제하던지 아니면 추가 내용을 기재해야 할 것으로 보여.
