#Step 01 — 환경 구축과 첫 Job

package com.example.batch.step01;

import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.job.builder.JobBuilder;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.batch.core.step.builder.StepBuilder;
import org.springframework.batch.repeat.RepeatStatus;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.transaction.PlatformTransactionManager;

@Configuration
public class HelloJobConfig {

    @Bean
    public Job helloJob(JobRepository jobRepository, Step helloStep) {
        return new JobBuilder("helloJob", jobRepository)
                .start(helloStep)
                .build();
    }

    @Bean
    public Step helloStep(JobRepository jobRepository, PlatformTransactionManager txManager) {
        return new StepBuilder("helloStep", jobRepository)
                .tasklet((contribution, chunkContext) -> {
                    System.out.println(">>> Hello, Spring Batch 5!");
                    return RepeatStatus.FINISHED;
                }, txManager)
                .build();
    }
}

@Bean
public Step exitCodeStep(JobRepository jobRepository, PlatformTransactionManager txManager) {
    return new StepBuilder("exitCodeStep", jobRepository)
            .tasklet((contribution, chunkContext) -> {
                long processed = 0;                 // 처리 건수가 0이라고 가정
                if (processed == 0) {
                    // BatchStatus 는 COMPLETED 로 두고, ExitStatus 만 바꿉니다
                    contribution.setExitStatus(new ExitStatus("NO_DATA", "처리 대상이 없습니다"));
                }
                return RepeatStatus.FINISHED;
            }, txManager)
            .build();
}

@Bean
public Step failStep(JobRepository jobRepository, PlatformTransactionManager txManager) {
    return new StepBuilder("failStep", jobRepository)
            .tasklet((contribution, chunkContext) -> {
                throw new IllegalStateException("정산 원장이 잠겨 있습니다");
            }, txManager)
            .build();
}

package com.example.batch.step01;

/*
 * ============================================================================
 * Step 01 — 환경 구축과 첫 Job  :  본문 예제 모음
 * ============================================================================
 *
 * 실행 방법 (프로젝트 루트에서)
 *
 *   ./gradlew bootRun --args='--spring.batch.job.name=helloJob'
 *   ./gradlew bootRun --args='--spring.batch.job.name=helloJob greeting=hi runId(long)=7'
 *   ./gradlew bootRun --args='--spring.batch.job.name=exitCodeJob'
 *   ./gradlew bootRun --args='--spring.batch.job.name=failJob'
 *   ./gradlew bootRun --args='--spring.batch.job.name=twoStepJob'
 *
 * ⚠️ --spring.batch.job.name 을 빼면 이 파일의 Job 4개가 전부 실행됩니다 (본문 1-4).
 *
 * 메타데이터 초기화가 필요하면 project/index.md 의 P-10 (a) 스크립트를 쓰세요.
 * _SEQ 테이블은 절대 TRUNCATE 하지 마세요 (본문 1-12).
 * ============================================================================
 */

import org.springframework.batch.core.ExitStatus;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.job.builder.JobBuilder;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.batch.core.step.builder.StepBuilder;
import org.springframework.batch.repeat.RepeatStatus;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.transaction.PlatformTransactionManager;

public final class Practice {

    private Practice() {
    }

    // =========================================================================
    // [1-1] 가장 단순한 Job — Tasklet 하나
    // =========================================================================
    //
    // 주목할 점 4가지
    //   (1) @EnableBatchProcessing 이 없다        → Boot 3.x 자동설정이 대신한다 (Step 02)
    //   (2) new JobBuilder(name, jobRepository)   → 5.0 에서 JobBuilderFactory 삭제
    //   (3) new StepBuilder(name, jobRepository)  → 5.0 에서 StepBuilderFactory 삭제
    //   (4) .tasklet(tasklet, txManager)          → 5.0 에서 트랜잭션 매니저가 인자로 승격
    //
    @Configuration
    public static class HelloJobConfig {

        @Bean
        public Job helloJob(JobRepository jobRepository, Step helloStep) {
            return new JobBuilder("helloJob", jobRepository)
                    .start(helloStep)
                    .build();
        }

        @Bean
        public Step helloStep(JobRepository jobRepository, PlatformTransactionManager txManager) {
            return new StepBuilder("helloStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println(">>> Hello, Spring Batch 5!");
                        // FINISHED = "더 반복하지 마라"
                        // CONTINUABLE 을 반환하면 같은 Tasklet 이 새 트랜잭션에서 또 호출된다
                        return RepeatStatus.FINISHED;
                    }, txManager)
                    .build();
        }
    }

    // =========================================================================
    // [1-13] BatchStatus 는 COMPLETED 로 두고 ExitStatus 만 커스텀으로 바꾸기
    // =========================================================================
    //
    // 실행 후 확인:
    //   SELECT STATUS, EXIT_CODE FROM BATCH_JOB_EXECUTION ORDER BY JOB_EXECUTION_ID DESC LIMIT 1;
    //   → STATUS = COMPLETED, EXIT_CODE = NO_DATA 여야 정상.
    //
    // 이 NO_DATA 를 Step 10 의 .on("NO_DATA").to(...) 분기 조건으로 쓰게 된다.
    //
    @Configuration
    public static class ExitCodeJobConfig {

        @Bean
        public Job exitCodeJob(JobRepository jobRepository, Step exitCodeStep) {
            return new JobBuilder("exitCodeJob", jobRepository)
                    .start(exitCodeStep)
                    .build();
        }

        @Bean
        public Step exitCodeStep(JobRepository jobRepository, PlatformTransactionManager txManager) {
            return new StepBuilder("exitCodeStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        long processed = 0L;   // 처리 대상이 없었다고 가정
                        if (processed == 0L) {
                            contribution.setExitStatus(
                                    new ExitStatus("NO_DATA", "처리 대상이 없습니다"));
                        }
                        return RepeatStatus.FINISHED;
                    }, txManager)
                    .build();
        }
    }

    // =========================================================================
    // [1-14] 일부러 실패시키기 — BatchStatus 와 ExitStatus 가 갈라지는 순간
    // =========================================================================
    //
    // 이 Job 은 실패하는 것이 정상입니다. ERROR 로그와 스택트레이스가 나옵니다.
    //
    // 종료 코드 확인 (배치 운영에서 가장 먼저 확인해야 할 것):
    //   ./gradlew bootJar -q
    //   java -jar build/libs/spring-batch5-lab-1.0.0.jar \
    //        --spring.batch.job.name=failJob > /dev/null 2>&1; echo "exit=$?"
    //   → exit=1 이어야 한다. exit=0 이면 스케줄러가 실패를 못 알아챈다.
    //
    @Configuration
    public static class FailJobConfig {

        @Bean
        public Job failJob(JobRepository jobRepository, Step failStep) {
            return new JobBuilder("failJob", jobRepository)
                    .start(failStep)
                    .build();
        }

        @Bean
        public Step failStep(JobRepository jobRepository, PlatformTransactionManager txManager) {
            return new StepBuilder("failStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        throw new IllegalStateException("정산 원장이 잠겨 있습니다");
                    }, txManager)
                    .build();
        }
    }

    // =========================================================================
    // [1-15+] Step 두 개짜리 Job — BATCH_STEP_EXECUTION 에 행이 2개 생기는지 확인
    // =========================================================================
    //
    // 로그에서 "Executing step:" 이 두 번 나와야 정상입니다 (본문 1-3 의 함정).
    //
    // 확인:
    //   SELECT STEP_NAME, STATUS, COMMIT_COUNT, EXIT_CODE
    //   FROM BATCH_STEP_EXECUTION
    //   WHERE JOB_EXECUTION_ID = (SELECT MAX(JOB_EXECUTION_ID) FROM BATCH_JOB_EXECUTION)
    //   ORDER BY STEP_EXECUTION_ID;
    //
    @Configuration
    public static class TwoStepJobConfig {

        @Bean
        public Job twoStepJob(JobRepository jobRepository, Step firstStep, Step secondStep) {
            return new JobBuilder("twoStepJob", jobRepository)
                    .start(firstStep)
                    .next(secondStep)     // .next() 로 이어 붙인다 (Step 02 에서 자세히)
                    .build();
        }

        @Bean
        public Step firstStep(JobRepository jobRepository, PlatformTransactionManager txManager) {
            return new StepBuilder("firstStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println(">>> [1] 정산 대상 집계");
                        return RepeatStatus.FINISHED;
                    }, txManager)
                    .build();
        }

        @Bean
        public Step secondStep(JobRepository jobRepository, PlatformTransactionManager txManager) {
            return new StepBuilder("secondStep", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        // chunkContext 로 현재 실행 정보에 접근할 수 있다
                        String jobName = chunkContext.getStepContext()
                                .getStepExecution().getJobExecution()
                                .getJobInstance().getJobName();
                        Long execId = chunkContext.getStepContext()
                                .getStepExecution().getJobExecutionId();
                        System.out.println(">>> [2] " + jobName + " / jobExecutionId=" + execId);
                        return RepeatStatus.FINISHED;
                    }, txManager)
                    .build();
        }
    }

    // =========================================================================
    // [1-6 ~ 1-15] 메타데이터 확인용 SQL 모음
    // -------------------------------------------------------------------------
    // 코드에서 실행하지 않습니다. mysql CLI 에 복사해서 쓰세요.
    //
    //   mysql -h127.0.0.1 -P3308 -ubatch -pbatch1234 batchdb
    // =========================================================================
    public static final String METADATA_QUERIES = """
            -- [1-6] BATCH_JOB_INSTANCE : "무엇을 돌리는 일인가"
            SELECT * FROM BATCH_JOB_INSTANCE;
            SHOW CREATE TABLE BATCH_JOB_INSTANCE;        -- (JOB_NAME, JOB_KEY) UNIQUE 확인

            -- [1-7] BATCH_JOB_EXECUTION : "몇 번째 시도인가"
            SELECT JOB_EXECUTION_ID, JOB_INSTANCE_ID, VERSION,
                   CREATE_TIME, START_TIME, END_TIME, STATUS, EXIT_CODE
            FROM BATCH_JOB_EXECUTION ORDER BY JOB_EXECUTION_ID;

            -- 좀비 실행 감시 쿼리 (운영에서 알람으로 걸어 둘 것)
            SELECT * FROM BATCH_JOB_EXECUTION
            WHERE STATUS = 'STARTED' AND END_TIME IS NULL;

            -- [1-8] 5.0 에서 구조가 바뀐 파라미터 테이블
            DESC BATCH_JOB_EXECUTION_PARAMS;
            SELECT * FROM BATCH_JOB_EXECUTION_PARAMS;

            -- [1-9] Job 범위 ExecutionContext
            SELECT JOB_EXECUTION_ID, SHORT_CONTEXT, SERIALIZED_CONTEXT
            FROM BATCH_JOB_EXECUTION_CONTEXT;

            -- [1-10] 모든 카운트의 원천. READ = FILTER + WRITE 등식을 확인한다.
            SELECT STEP_NAME, STATUS, COMMIT_COUNT,
                   READ_COUNT, FILTER_COUNT, WRITE_COUNT,
                   READ_COUNT - FILTER_COUNT - WRITE_COUNT AS leak,
                   READ_SKIP_COUNT, PROCESS_SKIP_COUNT, WRITE_SKIP_COUNT, ROLLBACK_COUNT,
                   EXIT_CODE
            FROM BATCH_STEP_EXECUTION ORDER BY STEP_EXECUTION_ID;

            -- [1-11] Step 범위 ExecutionContext — 재시작 지점이 저장되는 곳
            SELECT STEP_EXECUTION_ID, SHORT_CONTEXT FROM BATCH_STEP_EXECUTION_CONTEXT;

            -- [1-12] 채번 테이블 3종. 각각 정확히 1행이어야 한다. TRUNCATE 금지.
            SELECT 'JOB'  t, ID, UNIQUE_KEY FROM BATCH_JOB_SEQ
            UNION ALL SELECT 'JOB_EXEC',  ID, UNIQUE_KEY FROM BATCH_JOB_EXECUTION_SEQ
            UNION ALL SELECT 'STEP_EXEC', ID, UNIQUE_KEY FROM BATCH_STEP_EXECUTION_SEQ;

            -- [1-15] 실행 이력 한눈에 보기 (즐겨찾기 추천)
            SELECT i.JOB_INSTANCE_ID inst, i.JOB_NAME, e.JOB_EXECUTION_ID exec_id,
                   e.STATUS, e.EXIT_CODE,
                   TIMESTAMPDIFF(MICROSECOND, e.START_TIME, e.END_TIME)/1000 AS ms,
                   (SELECT COUNT(*) FROM BATCH_STEP_EXECUTION s
                     WHERE s.JOB_EXECUTION_ID = e.JOB_EXECUTION_ID) AS steps
            FROM BATCH_JOB_INSTANCE i
            JOIN BATCH_JOB_EXECUTION e ON e.JOB_INSTANCE_ID = i.JOB_INSTANCE_ID
            ORDER BY e.JOB_EXECUTION_ID;
            """;
}

package com.example.batch.step01;

/*
 * ============================================================================
 * Step 01 — 연습문제 (6문제)
 * ============================================================================
 *
 * 규칙
 *   - "// 여기에 작성:" 아래를 채웁니다.
 *   - 각 문제를 풀고 나면 반드시 실행해서 BATCH_* 테이블을 직접 SELECT 하세요.
 *     이 스텝의 목적은 "코드를 쓰는 것"이 아니라 "메타데이터를 읽는 것"입니다.
 *   - 정답은 Solution.java. 먼저 풀어 본 뒤에 여세요.
 *
 * 실행
 *   ./gradlew bootRun --args='--spring.batch.job.name=<jobName>'
 * ============================================================================
 */

import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.transaction.PlatformTransactionManager;

public final class Exercise {

    private Exercise() {
    }

    // =========================================================================
    // 문제 1. Step 두 개를 순서대로 실행하는 Job
    // -------------------------------------------------------------------------
    // 요구사항
    //   - Job 이름: ex1Job
    //   - Step 이름: ex1StepA, ex1StepB  (이 순서로 실행)
    //   - 각 Step 은 자기 이름을 System.out 으로 출력하고 끝난다
    //
    // 실행 후 확인할 것
    //   (a) 로그에 "Executing step:" 이 몇 번 나오는가?
    //   (b) SELECT STEP_NAME, STATUS FROM BATCH_STEP_EXECUTION
    //       WHERE JOB_EXECUTION_ID = (SELECT MAX(JOB_EXECUTION_ID) FROM BATCH_JOB_EXECUTION);
    //       → 행이 몇 개인가?
    // =========================================================================
    @Configuration
    public static class Ex1Config {

        @Bean
        public Job ex1Job(JobRepository jobRepository, Step ex1StepA, Step ex1StepB) {
            // 여기에 작성: JobBuilder 로 ex1StepA → ex1StepB 순서의 Job 을 만드세요
            return null;
        }

        @Bean
        public Step ex1StepA(JobRepository jobRepository, PlatformTransactionManager txManager) {
            // 여기에 작성:
            return null;
        }

        @Bean
        public Step ex1StepB(JobRepository jobRepository, PlatformTransactionManager txManager) {
            // 여기에 작성:
            return null;
        }
    }

    // =========================================================================
    // 문제 2. RepeatStatus.CONTINUABLE 과 COMMIT_COUNT
    // -------------------------------------------------------------------------
    // 요구사항
    //   - Job 이름: ex2Job / Step 이름: ex2Step
    //   - Tasklet 이 CONTINUABLE 을 3번 반환한 뒤 4번째 호출에서 FINISHED 를 반환한다.
    //     (호출 횟수는 StepExecutionContext 가 아니라 필드/AtomicInteger 로 세도 됩니다)
    //   - 매 호출마다 몇 번째 호출인지 출력한다.
    //
    // ★ 실행하기 전에 예측을 적으세요. 이게 이 문제의 핵심입니다.
    //
    //   내 예측: Tasklet 호출 횟수 = ____ 회,  COMMIT_COUNT = ____
    //
    // 실행 후 확인
    //   SELECT STEP_NAME, COMMIT_COUNT, READ_COUNT, WRITE_COUNT
    //   FROM BATCH_STEP_EXECUTION WHERE STEP_NAME = 'ex2Step';
    //
    //   실제 값: 호출 ____ 회, COMMIT_COUNT = ____
    //   예측과 다르다면, 왜 다른지 한 줄로 적으세요:
    //   →
    // =========================================================================
    @Configuration
    public static class Ex2Config {

        @Bean
        public Job ex2Job(JobRepository jobRepository, Step ex2Step) {
            // 여기에 작성:
            return null;
        }

        @Bean
        public Step ex2Step(JobRepository jobRepository, PlatformTransactionManager txManager) {
            // 여기에 작성:
            return null;
        }
    }

    // =========================================================================
    // 문제 3. BatchStatus 는 COMPLETED, ExitStatus 만 SKIPPED
    // -------------------------------------------------------------------------
    // 요구사항
    //   - Job 이름: ex3Job / Step 이름: ex3Step
    //   - Step 이 정상 종료하되, ExitStatus 의 exitCode 는 "SKIPPED",
    //     exitDescription 은 "휴일이라 정산을 건너뜁니다" 로 만든다.
    //
    // 실행 후 확인 — 아래 결과가 나와야 정답입니다.
    //   SELECT STATUS, EXIT_CODE FROM BATCH_STEP_EXECUTION WHERE STEP_NAME='ex3Step';
    //   → STATUS = COMPLETED,  EXIT_CODE = SKIPPED
    //
    //   STATUS 까지 SKIPPED 로 바뀌었다면 잘못 푼 것입니다.
    //   (BatchStatus 는 enum 이라 SKIPPED 라는 값 자체가 없습니다)
    // =========================================================================
    @Configuration
    public static class Ex3Config {

        @Bean
        public Job ex3Job(JobRepository jobRepository, Step ex3Step) {
            // 여기에 작성:
            return null;
        }

        @Bean
        public Step ex3Step(JobRepository jobRepository, PlatformTransactionManager txManager) {
            // 여기에 작성:
            return null;
        }
    }

    // =========================================================================
    // 문제 4. EXIT_MESSAGE 에서 예외 클래스명만 추출하는 SQL
    // -------------------------------------------------------------------------
    // 배경
    //   실패한 JobExecution 의 EXIT_MESSAGE 에는 스택트레이스가 통째로 들어갑니다.
    //   첫 줄은 "java.lang.IllegalStateException: 정산 원장이 잠겨 있습니다" 형태입니다.
    //
    // 요구사항
    //   STATUS = 'FAILED' 인 JobExecution 에 대해
    //     JOB_EXECUTION_ID | 예외 FQCN | 예외 메시지 첫 줄
    //   을 뽑는 SQL 을 작성하세요. (Practice 의 failJob 을 한 번 돌려 두고 실행)
    //
    //   힌트: SUBSTRING_INDEX 를 두 번 씁니다.
    // =========================================================================
    public static final String EX4_SQL = """
            -- 여기에 작성:
            """;

    // =========================================================================
    // 문제 5. 최근 24시간 내 3초 이상 걸린 Job 찾기
    // -------------------------------------------------------------------------
    // 요구사항
    //   BATCH_JOB_INSTANCE 와 BATCH_JOB_EXECUTION 을 조인해
    //     JOB_NAME | JOB_EXECUTION_ID | 소요 밀리초 | STATUS
    //   를 소요시간 내림차순으로 뽑되,
    //     (a) 최근 24시간 안에 시작한 것만
    //     (b) 3초(3000ms) 이상 걸린 것만
    //   으로 제한하세요.
    //
    //   ⚠️ 반드시 고려할 것 2가지가 있습니다. 무엇인지 생각하고 SQL 에 반영하세요.
    //      - 아직 안 끝난(혹은 죽어서 안 끝난 것으로 남은) 실행을 어떻게 처리할 것인가
    //      - "3초 이상"을 초 단위로 빼면 무슨 문제가 생기는가
    // =========================================================================
    public static final String EX5_SQL = """
            -- 여기에 작성:
            """;

    // =========================================================================
    // 문제 6. 타입 표기가 JobInstance 를 가르는가
    // -------------------------------------------------------------------------
    // 절차
    //   (1) ./gradlew bootRun --args='--spring.batch.job.name=helloJob runDate(string)=2025-03-01'
    //   (2) ./gradlew bootRun --args='--spring.batch.job.name=helloJob runDate=2025-03-01'
    //
    //   (2) 는 "already completed" 로 스킵될까요, 새로 실행될까요?
    //
    // 확인
    //   SELECT JOB_INSTANCE_ID, JOB_NAME, JOB_KEY FROM BATCH_JOB_INSTANCE
    //   WHERE JOB_NAME = 'helloJob';
    //
    //   SELECT JOB_EXECUTION_ID, PARAMETER_NAME, PARAMETER_TYPE, PARAMETER_VALUE
    //   FROM BATCH_JOB_EXECUTION_PARAMS WHERE PARAMETER_NAME = 'runDate';
    //
    // 답을 여기에 적으세요.
    //   (a) (2)는 스킵되었나 실행되었나?                        →
    //   (b) JobInstance 가 몇 개 생겼나?                        →
    //   (c) 두 JOB_KEY 는 같은가 다른가?                        →
    //   (d) 그 이유를 한 문장으로:                              →
    //   (e) 이 현상이 정산 배치에서 만들 수 있는 사고는?        →
    // =========================================================================
}

package com.example.batch.step01;

/*
 * ============================================================================
 * Step 01 — 연습문제 정답 및 해설
 * ============================================================================
 * Exercise.java 를 먼저 풀어 본 뒤에 보세요.
 * ============================================================================
 */

import org.springframework.batch.core.ExitStatus;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.job.builder.JobBuilder;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.batch.core.step.builder.StepBuilder;
import org.springframework.batch.repeat.RepeatStatus;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.transaction.PlatformTransactionManager;

import java.util.concurrent.atomic.AtomicInteger;

public final class Solution {

    private Solution() {
    }

    // =========================================================================
    // 정답 1. Step 두 개를 순서대로
    // =========================================================================
    //
    // 핵심은 .start(첫Step).next(다음Step) 입니다.
    //
    // 왜 Step 을 @Bean 파라미터로 주입받는가?
    //   ex1Job(...) 안에서 ex1StepA(jobRepository, txManager) 를 "직접 호출"해도
    //   컴파일은 됩니다. @Configuration 클래스는 CGLIB 프록시라 대개 같은 빈이 돌아오지만,
    //   프록시가 걸리지 않는 상황(@Configuration(proxyBeanMethods = false), 정적 중첩 구성 등)에서는
    //   컨테이너가 모르는 Step 인스턴스가 하나 더 만들어집니다.
    //   그 Step 은 StepExecutionListener 등록도, 프록시도 안 걸린 "그림자 Step" 입니다.
    //   → 에러는 안 나고 동작만 미묘하게 달라지는, 이 코스가 경계하는 종류의 버그입니다.
    //   메서드 파라미터로 받으면 컨테이너가 만든 그 빈임이 보장됩니다.
    //
    // 확인 결과
    //   로그에 "Executing step:" 이 2번,
    //   BATCH_STEP_EXECUTION 에 행이 2개 (ex1StepA, ex1StepB).
    //   BATCH_JOB_EXECUTION 에는 여전히 1행입니다. Step 이 늘어도 JobExecution 은 하나입니다.
    //
    @Configuration
    public static class Sol1Config {

        @Bean
        public Job ex1Job(JobRepository jobRepository, Step ex1StepA, Step ex1StepB) {
            return new JobBuilder("ex1Job", jobRepository)
                    .start(ex1StepA)
                    .next(ex1StepB)
                    .build();
        }

        @Bean
        public Step ex1StepA(JobRepository jobRepository, PlatformTransactionManager txManager) {
            return new StepBuilder("ex1StepA", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println(">>> ex1StepA");
                        return RepeatStatus.FINISHED;
                    }, txManager)
                    .build();
        }

        @Bean
        public Step ex1StepB(JobRepository jobRepository, PlatformTransactionManager txManager) {
            return new StepBuilder("ex1StepB", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println(">>> ex1StepB");
                        return RepeatStatus.FINISHED;
                    }, txManager)
                    .build();
        }
    }

    // =========================================================================
    // 정답 2. CONTINUABLE 3번 → 호출 4회, COMMIT_COUNT = 4
    // =========================================================================
    //
    // ★ 이 문제의 답이 4 인 것이 이 스텝에서 가장 놀라운 지점입니다.
    //
    // 흔한 오답: "Tasklet 은 한 번의 작업 단위니까 COMMIT_COUNT = 1"
    //
    // 실제 동작:
    //   TaskletStep 은 내부에 RepeatTemplate 를 두고 다음을 반복합니다.
    //
    //     while (true) {
    //         트랜잭션 시작
    //           RepeatStatus rs = tasklet.execute(contribution, chunkContext);
    //           JobRepository.update(stepExecution)      ← 메타데이터도 같은 트랜잭션
    //         커밋 (commitCount++)
    //         if (rs == FINISHED) break;
    //     }
    //
    //   즉 "Tasklet 호출 1회 = 트랜잭션 1개 = 커밋 1회" 입니다.
    //   CONTINUABLE 을 3번 반환하면 호출은 1,2,3(CONTINUABLE) + 4(FINISHED) = 4회이고,
    //   커밋도 4회입니다.
    //
    // 왜 이게 중요한가:
    //   (1) CONTINUABLE 을 쓰는 Tasklet 은 "전체가 하나의 트랜잭션"이 아닙니다.
    //       3번째 호출에서 예외가 나도 1,2번째가 한 일은 이미 커밋되어 되돌아가지 않습니다.
    //       "루프 도는 Tasklet 을 만들었는데 실패했더니 절반만 반영됐다"의 원인이 이것입니다.
    //   (2) 반대로 이 성질 덕에 대용량 삭제 같은 작업을 CONTINUABLE 로 잘라
    //       긴 트랜잭션과 락 점유를 피할 수 있습니다. (Step 04 에서 다룹니다)
    //
    // ⚠️ 아래 AtomicInteger 는 "빈 하나 = 상태 하나"라서 학습용으로만 안전합니다.
    //    Step 빈은 싱글턴이라 이 카운터는 JVM 이 살아 있는 동안 유지됩니다.
    //    같은 프로세스에서 Job 을 두 번 돌리면 카운터가 이어져 결과가 달라집니다.
    //    운영 코드에서 Tasklet 에 상태를 두면 안 되는 이유이고, Step 02 에서 다시 다룹니다.
    //    올바른 자리는 StepExecutionContext 입니다 (Step 09).
    //
    @Configuration
    public static class Sol2Config {

        @Bean
        public Job ex2Job(JobRepository jobRepository, Step ex2Step) {
            return new JobBuilder("ex2Job", jobRepository)
                    .start(ex2Step)
                    .build();
        }

        @Bean
        public Step ex2Step(JobRepository jobRepository, PlatformTransactionManager txManager) {
            AtomicInteger calls = new AtomicInteger(0);
            return new StepBuilder("ex2Step", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        int n = calls.incrementAndGet();
                        System.out.println(">>> tasklet call #" + n);
                        return (n < 4) ? RepeatStatus.CONTINUABLE : RepeatStatus.FINISHED;
                    }, txManager)
                    .build();
        }
    }

    // =========================================================================
    // 정답 3. ExitStatus 만 SKIPPED
    // =========================================================================
    //
    // 정답 코드는 contribution.setExitStatus(new ExitStatus("SKIPPED", "...")) 한 줄입니다.
    // 중요한 것은 "왜 contribution 인가" 입니다.
    //
    //   contribution.setExitStatus(...)      ← StepContribution 에 담아 둔다.
    //                                          청크(=여기서는 Tasklet 호출) 트랜잭션이
    //                                          커밋될 때 StepExecution 에 반영된다.
    //                                          롤백되면 반영되지 않는다. ✔ 정석
    //
    //   stepExecution.setExitStatus(...)     ← StepExecution 에 즉시 쓴다.
    //                                          트랜잭션이 롤백돼도 이 값은 남는다.
    //                                          "실패한 청크가 남긴 성공 신호"가 되어
    //                                          Step 10 의 Flow 분기를 조용히 오작동시킨다.
    //
    // 즉 둘 다 "동작은" 합니다. 차이는 실패했을 때만 드러납니다.
    // 이것이 이 코스가 말하는 "에러 없이 조용히 틀리는 코드"의 전형입니다.
    //
    // 또 하나: BatchStatus 에는 SKIPPED 라는 값이 없습니다.
    //   COMPLETED / STARTING / STARTED / STOPPING / STOPPED / FAILED / ABANDONED / UNKNOWN
    //   8개가 전부이고 enum 이라 늘릴 수 없습니다.
    //   "업무적으로 의미 있는 종료 사유"는 전부 ExitStatus 쪽에 실어야 합니다.
    //
    @Configuration
    public static class Sol3Config {

        @Bean
        public Job ex3Job(JobRepository jobRepository, Step ex3Step) {
            return new JobBuilder("ex3Job", jobRepository)
                    .start(ex3Step)
                    .build();
        }

        @Bean
        public Step ex3Step(JobRepository jobRepository, PlatformTransactionManager txManager) {
            return new StepBuilder("ex3Step", jobRepository)
                    .tasklet((contribution, chunkContext) -> {
                        contribution.setExitStatus(
                                new ExitStatus("SKIPPED", "휴일이라 정산을 건너뜁니다"));
                        return RepeatStatus.FINISHED;
                    }, txManager)
                    .build();
        }
    }

    // =========================================================================
    // 정답 4. EXIT_MESSAGE 에서 예외 클래스명 추출
    // =========================================================================
    //
    // EXIT_MESSAGE 의 첫 줄은
    //   java.lang.IllegalStateException: 정산 원장이 잠겨 있습니다
    // 이고 그 뒤로 "\n\tat ..." 스택 프레임이 이어집니다.
    //
    //   SUBSTRING_INDEX(EXIT_MESSAGE, '\n', 1)  → 첫 줄만
    //   SUBSTRING_INDEX(첫줄, ':', 1)           → 콜론 앞 = FQCN
    //   SUBSTRING_INDEX(첫줄, ': ', -1)         → 콜론 뒤 = 메시지
    //
    // ⚠️ 한계 두 가지를 반드시 알고 쓰세요.
    //   (1) EXIT_MESSAGE 는 VARCHAR(2500) 입니다. 깊은 스택트레이스는 잘립니다.
    //       "Caused by" 가 잘려 나가면 진짜 원인을 여기서는 절대 볼 수 없습니다.
    //   (2) 성공한 실행은 EXIT_MESSAGE 가 빈 문자열이라 WHERE 로 걸러야 합니다.
    //
    // 결론: 메타데이터는 "무엇이 몇 시에 어떤 상태로 끝났나"를 보는 곳이고,
    //       "왜 그랬나"는 애플리케이션 로그에서 봐야 합니다. 대체재가 아닙니다.
    //
    public static final String EX4_SQL = """
            SELECT
              e.JOB_EXECUTION_ID,
              SUBSTRING_INDEX(SUBSTRING_INDEX(e.EXIT_MESSAGE, '\\n', 1), ':', 1)  AS exception_class,
              SUBSTRING_INDEX(SUBSTRING_INDEX(e.EXIT_MESSAGE, '\\n', 1), ': ', -1) AS exception_message,
              i.JOB_NAME,
              e.START_TIME
            FROM BATCH_JOB_EXECUTION e
            JOIN BATCH_JOB_INSTANCE i ON i.JOB_INSTANCE_ID = e.JOB_INSTANCE_ID
            WHERE e.STATUS = 'FAILED'
              AND e.EXIT_MESSAGE <> ''
            ORDER BY e.JOB_EXECUTION_ID DESC;
            """;
    //
    // 결과 예시
    // +------------------+---------------------------------+----------------------------+----------+
    // | JOB_EXECUTION_ID | exception_class                 | exception_message          | JOB_NAME |
    // +------------------+---------------------------------+----------------------------+----------+
    // |                4 | java.lang.IllegalStateException | 정산 원장이 잠겨 있습니다  | failJob  |
    // +------------------+---------------------------------+----------------------------+----------+

    // =========================================================================
    // 정답 5. 최근 24시간 내 3초 이상 걸린 Job
    // =========================================================================
    //
    // 두 개의 함정이 있었습니다.
    //
    // (1) END_TIME IS NOT NULL 을 반드시 붙일 것
    //     kill -9 나 OOM 으로 죽은 실행은 STATUS='STARTED', END_TIME=NULL 로 남습니다(본문 1-7).
    //     이 조건이 없으면 TIMESTAMPDIFF 결과가 NULL 이 되어 비교가 UNKNOWN 이 되고,
    //     그 행은 조용히 결과에서 빠집니다. "안 나온다"는 사실조차 눈치채기 어렵습니다.
    //     차라리 좀비는 별도 쿼리로 따로 감시하는 것이 낫습니다.
    //
    // (2) 초 단위로 빼면 안 됩니다
    //     TIMESTAMPDIFF(SECOND, ...) 는 3.9초를 3 으로 내립니다.
    //     "3초 이상"을 SECOND >= 3 으로 쓰면 2.9초도 2 라서 빠지고 경계가 흐려집니다.
    //     MySQL 의 DATETIME(6) 을 살려 MICROSECOND 로 재고 1000 으로 나누는 것이 정확합니다.
    //
    // (3) 보너스 — START_TIME 기준으로 24시간을 자르되, 인덱스가 없다는 점도 기억하세요.
    //     BATCH_JOB_EXECUTION 에는 START_TIME 인덱스가 기본으로 없습니다.
    //     이력이 수십만 건 쌓이면 이 쿼리가 풀스캔입니다. 운영에서는
    //     주기적으로 오래된 메타데이터를 아카이빙하거나 인덱스를 추가합니다(Step 14).
    //
    public static final String EX5_SQL = """
            SELECT
              i.JOB_NAME,
              e.JOB_EXECUTION_ID,
              TIMESTAMPDIFF(MICROSECOND, e.START_TIME, e.END_TIME) / 1000 AS elapsed_ms,
              e.STATUS,
              e.EXIT_CODE,
              e.START_TIME
            FROM BATCH_JOB_EXECUTION e
            JOIN BATCH_JOB_INSTANCE i ON i.JOB_INSTANCE_ID = e.JOB_INSTANCE_ID
            WHERE e.START_TIME >= NOW() - INTERVAL 24 HOUR
              AND e.END_TIME IS NOT NULL
              AND TIMESTAMPDIFF(MICROSECOND, e.START_TIME, e.END_TIME) >= 3000000
            ORDER BY elapsed_ms DESC;

            -- 좀비는 따로 봅니다 (위 쿼리에서 조용히 빠지므로)
            SELECT i.JOB_NAME, e.JOB_EXECUTION_ID, e.START_TIME, e.STATUS
            FROM BATCH_JOB_EXECUTION e
            JOIN BATCH_JOB_INSTANCE i ON i.JOB_INSTANCE_ID = e.JOB_INSTANCE_ID
            WHERE e.END_TIME IS NULL
              AND e.STATUS IN ('STARTED', 'STARTING');
            """;

    // =========================================================================
    // 정답 6. 타입 표기는 JobInstance 를 가릅니다
    // =========================================================================
    //
    // (a) (2)는 스킵되지 않고 "새로 실행"됩니다.
    // (b) JobInstance 가 2개 생깁니다.
    // (c) 두 JOB_KEY 는 다릅니다.
    // (d) JOB_KEY 는 identifying 파라미터의 (이름, 값, 타입) 을 정렬해 이어 붙인 문자열의
    //     MD5 이기 때문입니다. 값 "2025-03-01" 이 같아도 타입이
    //     java.lang.String 과 (타입 미지정 시 추론되는) java.lang.String 으로
    //     같아 보일 수 있지만, 커맨드라인 파서는 (string) 명시 여부에 따라
    //     서로 다른 JobParameter 표현을 만들고 그 차이가 해시에 반영됩니다.
    //
    // (e) 사고 시나리오 — 이것이 이 문제의 진짜 목적입니다.
    //
    //     운영 스케줄러가 매일
    //         --spring.batch.job.name=settlementJob settleDate=2025-03-01
    //     로 정산 배치를 돌리고 있습니다.
    //     "타입을 명시하는 게 좋대"라는 리뷰 코멘트를 받아 누군가
    //         settleDate(string)=2025-03-01
    //     로 바꿉니다. 배포합니다.
    //
    //     그날 밤, 배치는 정상적으로 COMPLETED 로 끝납니다.
    //     로그도 깨끗합니다. 알람도 안 옵니다.
    //     그런데 3월 1일 정산이 "두 번" 실행되었습니다.
    //     새 JOB_KEY 라서 Spring Batch 는 이것을 완전히 새로운 일로 봤기 때문입니다.
    //
    //     settlement 테이블에 uk_settlement_order UNIQUE 제약이 있다면
    //     DuplicateKeyException 으로 시끄럽게 실패합니다 — 다행입니다.
    //     제약이 없었다면 정산 금액이 정확히 2배가 된 채로,
    //     아무 에러 없이, 아무도 모르게 넘어갑니다.
    //
    //     교훈 두 가지:
    //       1. 파라미터 타입 표기는 팀 컨벤션으로 고정하고 함부로 바꾸지 않는다.
    //       2. 제약조건은 "조용히 틀리는 것"을 "시끄럽게 실패하는 것"으로 바꿔 준다.
    //          비용을 아끼겠다고 UNIQUE 를 빼지 마세요.
    //
    // 확인 SQL
    public static final String EX6_SQL = """
            SELECT i.JOB_INSTANCE_ID, i.JOB_KEY,
                   p.PARAMETER_NAME, p.PARAMETER_TYPE, p.PARAMETER_VALUE, p.IDENTIFYING
            FROM BATCH_JOB_INSTANCE i
            JOIN BATCH_JOB_EXECUTION e  ON e.JOB_INSTANCE_ID = i.JOB_INSTANCE_ID
            JOIN BATCH_JOB_EXECUTION_PARAMS p ON p.JOB_EXECUTION_ID = e.JOB_EXECUTION_ID
            WHERE i.JOB_NAME = 'helloJob' AND p.PARAMETER_NAME = 'runDate'
            ORDER BY i.JOB_INSTANCE_ID;
            """;
}