久しぶりにSpringBatchに触り、自分なりに使い方を整理したかったので、書いた。

※あくまで私の一意見であり、どこかで実践編を書きたいと思う。

前提

SpringBatchを使おうとして、挫折しそうor挫折済みの人向け
この後出てくるSpringBatchの用語が分からない人は、まず本家のイントロダクションと用語を説明したページを読んでからの方が良い
上記を雑に読んだあと、実際に使ってみて感じた結果をまとめているので、本家で説明していることと違うことがあるかもしれない。

なぜSpringBatchを使おうとしたのか

非同期処理をしたいから

例えば、Web経由でリクエストを受け付けて、必要なロジックは裏でやるとか。
わりと、思いつきでもやりたくなっちゃうことがあると思う。（反省）

SpringBatchなら、
このBeanを定義して、

@Bean
public JobLauncher jobLauncher(JobRepository jobRepository) {
        SimpleJobLauncher jobLauncher = new SimpleJobLauncher();
        jobLauncher.setJobRepository(jobRepository);
        // 非同期処理を定義、並列数は３
    SimpleAsyncTaskExecutor taskExecutor = new SimpleAsyncTaskExecutor();
    taskExecutor.setConcurrencyLimit(3);
    jobLauncher.setTaskExecutor(taskExecutor);
        return jobLauncher;
}

実行する。

/** 非同期処理するようにしたJobLuncher */
@Autowired
JobLauncher jobLauncher;

/** 処理を定義したジョブ */
@Autowired
Job job;

public void execute(Long orderId) throws Exception{
    // 引数を定義する
    JobParameters jobParameters = new JobParametersBuilder().addLong(
         "order.id", orderId, true).toJobParameters();
    // 非同期処理　開始！
    jobLauncher.run(job, new JobParameters());
}

SpringBatchで困る人は、ここで詰まることはないと思う。
辛いのは、Jobの作り方だと思う。

自分で非同期処理の仕組みを作りたくないから

非同期処理を動かすだけなら、RunnableインターフェースかCallableインターフェースを実装し、Exetutorクラスたちに渡せばよい。

だが、複数人数で同じく非同期処理を作り始めたら、どうなるだろう。
リソースは枯渇し、GC連発で遅くなったり、OutOfMemoryErrorに悩まされるのではないかと思う。
これを防ぐなら、仕組みを作ることになるが、やりたくない。

SpringBatchなら、
そのような仕組みを自分で作らず、上記のような使い方を共有すれば良い。
Google先生に聞ける、ということは、とても強みだと思う。

かつ、自分でつくるよりもSpringBatchのほうが、高機能だ。
例えば、JobParameterなどの情報を使って分かる範囲で、多重実行抑止などをやってくれる。
上記の例では、order.idの値をみて、一度実行完了したJobを実行しないようにしてくれる。
トランザクション等も利用されているため、自分で考慮はしなくてよい。
　（この辺の挙動は、SpringBatchが嫌いになりそうにもなるけど）

大げさにはしたくないから

非同期処理を作ることが前提なら、RabbitMQやKafkaなど、Queueプロセスを立てることもあると思う。

だが、それらを立てるとなると運用が大変になる。
Queueプロセスが死んだら？NWが死んだら？監視は？

これらを考える手間を超えるほど、非同期処理をするメリット出るのは、処理件数がよっぽど多く、
ケースとしてはわりと少ないのではないかと思う。

SpringBatchなら、
いわゆるJava(Spring)プロセス＋RDBを使った普通の構成で作れる。
RDBを使っておらず、システム通じてプロセス１人だけなら、H2DBのような組み込みでも良い。

Chunk？Tasklet？どっち使えば良いの？

とりあえず、`Tasklet`１つで`Job`をつくればよい。

感覚的には、アドホックに、たまに動く非同期処理を想定している。
Chunkとか、StepやFlowでの分岐、Retry/Skipは全部忘れてよし。

DB１レコードにつきJobを１つ動かすイメージで、シンプルにJobを作ろう。

引数なしの関数を呼び出す

xxxService#execute()の処理を実行するだけ。簡単でしょ。


 @Configuration
 @EnableBatchProcessing
 public class BatchConfiguration {

    @Autowired
    private JobBuilderFactory jobBuilderFactory;

    @Autowired
    private StepBuilderFactory stepBuilderFactory;

    @Autowired
    private OrderService orderService;

    @Bean
    public JobLauncher jobLauncher(JobRepository jobRepository) {
        SimpleJobLauncher jobLauncher = new SimpleJobLauncher();
        jobLauncher.setJobRepository(jobRepository);
        jobLauncher.setTaskExecutor(new SimpleAsyncTaskExecutor());
        return jobLauncher;
    }

    @Bean
    public Job job(Step step1) throws Exception {
        return jobBuilderFactory.get("job1").incrementer(new RunIdIncrementer()).start(step1).build();
    }

    @Bean
    public Step step1(Tasklet tasklet1) {
        return stepBuilderFactory.get("step1").tasklet(tasklet1).build();
    }

    @Bean
    public Tasklet tasklet1() {
        // xxxService#execute()を実行する
        MethodInvokingTaskletAdapter tasklet = new MethodInvokingTaskletAdapter();
        tasklet.setTargetObject(orderService);
        tasklet.setTargetMethod("execute");
        return tasklet;
    }
 }

引数ありの関数を呼び出す

引数ありなら、こうなる。


    @StepScope
    @Bean
    public Tasklet tasklet1(@Value("#{jobParameters['order.id']}") Long orderId) {
        // xxxService#execute()を実行する
        MethodInvokingTaskletAdapter tasklet = new MethodInvokingTaskletAdapter();
        tasklet.setTargetObject(orderService);
        tasklet.setTargetMethod("execute");
        tasklet.setArguments(new Object[] { orderId });
        return tasklet;
    }
 }

例外があれば異常終了、Jobの再実行は可能な状態で終了する

例えば、業務上入れてはいけない数値がやってきたとか、DBアクセスエラーが起きたなど、
失敗とみなして、あとからやり直しをすることになる場合、とにかく例外を発生させればよい。

そうすれば、SpringBatchはJobの実行に失敗した、という情報を持ち、再実行を許してくれる。
かつロールバックも発生して、DBの書き込みもなくなる。

逆に、呼び出した関数が例外を発生させなければ、正常終了する。

異常終了したけど、ロールバックはさせないようにする

Jobは失敗だけどロールバックさせないようにもできる。
業務上の処理に失敗した時、失敗した状態にDBを更新することなどに使える。

    @Bean
    public Step step1(Tasklet tasklet1) {
        return stepBuilderFactory.get("step1").tasklet(tasklet1)
                .exceptionHandler(exceptionHandler()).build();
    }

    private ExceptionHandler exceptionHandler() {
        return new ExceptionHandler() {

            @Override
            public void handleException(RepeatContext context, Throwable throwable) throws Throwable {
                // 例外を投げず、終了する
                context.setTerminateOnly();
            }
        };
    }

上記のように、ExceptionHandlerを実装すれば良い。
かつその中で、失敗とみなす場合に呼び出すRepeatContext#setTerminateOnly()を使う。

トランザクション境界を意識して、Tasklet(Step)を複数に分ける

SpringBatchはTasklet(Step)の開始から終了までの間で、特に設定せずともトランザクションを有効にしてくれている。
そのため大変ありがたいことに、Taskletで実行した処理が例外を出力して異常終了した場合でも、その間に更新したレコードをロールバックしてくる。

しかし逆にいえば、１つのTasklet中で行われるDBの更新は、そのTaskletが終了するまでコミットされない。

だから、１つのTasklet中で行われるDBの更新をちゃんとコミットしたいなら、コミットしたい単位でTaskletを分割すればよい。


    @Bean
    public Job job(Step beforeStep1, Step inProgressStep2, Step afterStep3) throws Exception {
        return jobBuilderFactory.get("job1").incrementer(new RunIdIncrementer())
            .start(beforeStep1)
            .next(inProgressStep2)
            .next(afterStep3)
            .build();
    }

Job実行待ちが多いようなら、Chunkを使うかな

Job実行回数が多いなら、Job１回でまとめて処理できるようにする（つもり）。

例えば、
Taskletを使った場合は、DB１レコードにつきJobを１つ動かすイメージで作っていたのを、
Chunkを使った場合は、DB１レコードにつきChunkを１つ作るイメージで、
かつDBレコードを複数束ねた１リクエストにつきJobを１つ動かす。

ただ私の場合、使わなかったため、予想になっている。
使うとしたらどうなるかは、別途まとめたいと思う。

SpringBatch再入門 - 自分なりに使い方を整理してみた

前提