DevBoi

동일한 step을 파라미터만 변경해서 반복, 실행 반복되는 횟수는 동적으로 제어 만약 종료를 희망한다면, RepeatCallback에서 Enum으로 정의된 Continualbe과, Finished중에, Finished를 호출하면 된다. RepeatContxt RepeatCallBack메소드는 RepeatContext를 파라미터로 받는다. 해당 iterator가 종료되면, 해당 컨텍스트는 종료되고, 실행되는 동안은, context는 공유된다. 반복 중간에 RepeatTemplate은 CompletionPlolicy를 호출하고, ReapeatCOntext에 저장되어있는 값을 업데이트하라고 한다. 해당 Policy에게 종료할지를 물어본다. RepeatListener의 내용중, Aop같이 사용할 수 도 있다. ..

RepeatStatus 의 Constant 값은 Finished,Continuable값이 있는데 FInished로 반환하는 경우, job을 정상적으로 종료하고, Continuable로 반환하는 경우 job이 계속 구동되어야 하는 의미로 처음부터 다시 시작한다. 단순히 스프링 배치에서 제공하는 상수, ENUM이다.

Job에 파라미터를 전달하는 방법은 두가지가 있다. 1) Chunk Context 2) Late Binding StepScop,JobScope란? Bean 생성시점을 Step,Job시점으로 늦춘다. 만약 서버를 올릴때 tasklet을 한번에 모두 생성 시키면 한 tasklet에 대해서 동시에 여러 step들이 실행되면서 침범당할 수 있다. 이를 방지하기 위해서 사용한다. Late BInding을 사용하면 얻을수 있는 이점 -JobParameter를 특정 메서드가 실행하는 시점까지 지연시켜 할당할 수 있다. 즉 애플리케이션이 구동되는 시점이 아니라 비즈니스 로직이 구현되는 어디든 JobParameter를 할당하여 유연한 설계가 가능하다. 이게 뭔소리냐, Job Parameter가 StepContext , ..

Controller -> Job Launch helper -> Step -> Tasklet 으로 실무에서는 사용했었다. 젠킨스로 스케쥴링을 하고 해당 배치를 관리했었다. Job 인터셉트

ItemReader 배치 프로세스는 기본적으로 실시간으로 처리하기 어려울만큼, 방대한 데이터를 다룬다 ItemReader의 대응방식에서는 크게 커서,페이징 기반 이렇게 두가지가 있다. Cursor 형식 -현재 Cursor가 가리키는 곳의 데이터를 읽고, Cursor는 다음 데이터를 가리킨다. -ResultSet이 Open될때마다 next()메서드가 호출되어 DB의 데이터가 반환되고, 객체와 매핑이 이루어진다. -DB connection은 배치 처리가 완료될 떄까지 데이터를 읽어오기 때문에 DB연결시간이 길다. -모든 데이터를 메모리에 저장하기 때문에 메모리 사용량이 많다. -Connection 시간과 메모리를 충분히 감당할수 있다면, 대용량 데이터 처리에 적합하다. (Fetch Size로 조절) Pagi..

Tasklet은 단계 내에서 단일 테스크를 수행하기 위함입니다. 각 단계는 하나의 정의된 작업만 수행한다. ex. Csv파일에서 행을 읽고, 사람들의 나이를 계산해서, 새로운 파일로 쓰는 배치작업이 있다고 하자 이런식으로 각각의 모듈별로 다 Tasklet을 구현하고, 안에 execute 메소드를 오버라이드 해야한다. Tasklet은 단순하게 처리할 수 있는 장점이 있지만, 대용량을 감당하기엔 부하를 감당할 수 없다. 따라서 Chunk를 통해서 쪼개서 넣을 필요가 있는데 Tasklet으로도 쪼개서 넣을수 있지만 가독성이 많이 떨어진다. Tasklet을 사용한 Task 기반처리 -배치 처리 과정이 비교적 쉬운 경우 쉽게 사용 -대량 처리를 하는 경우 복잡 -하나의 큰 덩어리를 여러 덩어리로 나누어 처리하기 ..

Spring Batch에서 Chunk란 데이터 덩어리로 작업할때 각 커밋 사이에 처리되는 row수를 얘기한다. 즉, Chunk 지향 처리는 한번에 하나씩 데이터를 읽어, Chunk라는 덩어리를 만들고, Chunk 단위로 트랜잭션을 다루는 것을 의미한다. Chunk 단위로 트랜잭션을 수행하기 때문에, 실패할 경우엔 해당 Chunk 만큼만 롤백이 되고, 커밋된 트랜잭션 범위까지는 반영이 된다는 것이다. commit - interval : reader - processor가 commit-interval 만큼 반복된 후, 가공된 데이터를 writer에서 bulk처리하는 구조이다. 청크 지향을 사용해야하는 이유는 뭐지? 일반적으로 대용량 데이터를 처리하는 배치 프로세스 특성상, 대량 데이터를 하나의 트랜잭션으로 ..

1. MultiThread 멀티 쓰레드 스탭은, 싱글 쓰레드 스탭보다 조금 더 빠르게 Chunk 단위로 작업을 처리할 가능성이 있다. 멀티 쓰레드 스탭은 TaskExecutorRepeatTemplate을 사용해 처리된다. Job에 해당 하는 Step -> 해당 템플릿을 통해서, Chunk단위로 작업이 처리된다. 1. Job이 처리되고 Step이 처리된다. 2. Step은 TaskExecutorRepeatTemplate을 생성하고, 각 쓰레드 수만큼 Runnable 객체를 만들어 실행한다. 3. 생성된 Runnable은 RepeatCallback을 호출한다. 4.RepeatCallBack함수는 ChunkOrientedTasklet을 수행하고, 독립적으로 ItemReader,ItemProcessor,Item..

Chunk란 데이터 덩어리로 작업할때 커밋사이에 작업되는 Row수이다. 즉, Chunk 지향 처리란, 한번에 하나씩 데이터를 읽어 Chunk라는 덩어리를 만들고, Chunk단위로 트랜잭션 처리를 하는 것을 의미한다. Chunk 단위로 트랜잭션을 수행하기 때문에, 실패에 대한 롤백도 해당 Chunk 단위로 되고 반영도 Chunk단위로 커밋이 된다. 해당 과 같은 구조로 동작한다. Reader에서 데이터를 읽고, Processor에서 가공하며, Chunk의 단위 별로 작동한다. Reader에서 쓰는 Paging은 데이터 조회에 대한 량이고, Chunk는 , 실제 한 트랜잭션당 반영되는 Row의 수이다. 즉 Reader 와 Processor가 일정 크기의 데이터를 가공하고 보관하여 저장하고 해당 Chunk s..

Spring Batch에서는 배치에 대한 실패가 발생했을 경우, Retry 관련 기능을 제공해준다. Retry 는 ItemReader에서는 동작하지 않는다. Writer, Processor에서만 동작한다. 따라서 ItemReader에서는 Skip만 지원한다는 것을 알아두자 Step은 기본적으로 Repeatable 템플릿을 사용한다. 하지만 실행될때 Retry Template에 실행을 위임한다. - ItemProcessor ItemProcessor에서 예외가 발생한다. Retry Template은 Repeat Template으로 돌아간다. Reader로 부터 다시 값을 요청하는 것이 아니라, 캐싱해서 가지고 있는 Input chunck를 가지고 와서 1부터 다시 프로세스를 동작한다. skip 과 다르게 실..