아직은 어색하고 서먹서먹하니 존댓말로 질문드립니다. 인프피니까 이해좀.. 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 까지의 기본 내용과 원리를 살펴봤잖아 ? 그렇다 하더라도 혼란을 줄 수 있기 때문에 해당 부분은 삭제하던지 아니면 추가 내용을 기재해야 할 것으로 보여.
명령어에서 startDateTime, endDateTime 의 jobParameters 부재 코드에서 @StepScope 어노테이션과 startDateTime, endDateTime 의 jobParameters 파라미터 부재 1번은 다른 사람이 심지어 이전에 쓴 문제더라고 ? 아마 형이 반영 안한건 모아서 한번에 수정할 계획인거 같아 보이네. 2번의 경우에는 @StepScope 도 빠져서 JobParameter 를 입력해도 오류가 발생했어. 또한 해당 메소드의 파라미터 부분을 1번과 마찬가지로 jobparameter로 받아야 할 것으로 보여져. 읽다가 하나씩 돌려보는데, 오류 터져서 놀라가지고 시간을 좀 썼어, 형. 1번은 내가 이해하는데, 2번은 형 실수가 좀 큰듯.
질문 가이드 읽고 삭제 후 오타제보 JobScope와 StepScope 사용 시 주의사항 ... 2. Step 빈에는 @StepScope와 @JobScope와를 사용하지 말라. -> @Step 빈에는 @StepScope 와 @JobScope 와 를 사용하지 말라 -> 말이 확실히 이상해
형 스프링부트 4에서는 jdbc starter 추가 안하면 안되던데 뭐지 ```build.gradle.kts description = "batch" dependencies { implementation("org.springframework.boot:spring-boot-starter-jdbc") implementation("org.springframework.boot:spring-boot-starter-batch") implementation("org.springframework.boot:spring-boot-h2console") runtimeOnly("com.h2database:h2") testImplementation("org.springframework.boot:spring-boot-starter-batch-test") } ``` implementation("org.springframework.boot:spring-boot-starter-jdbc") 위 처럼 의존성 명시적으로 처리해주기 전에는 아래 에러떳었어. Could not autowire. No beans of 'PlatformTransactionManager' type found.
