ここでは、チャンクモデルとタスクレットモデルの使い分けについて、それぞれの特徴を整理することで説明する。 なお、説明において、以降の章で詳細な説明をする事項もあるため、適宜対応する章を参照して欲しい。

また、以降の内容は考え方の一例として捉えて欲しい。制約や推奨事項ではない。 ユーザやシステムの特性に応じてジョブを作成する際の参考にしてほしい。

以下に、チャンクモデルとタスクレットモデルの主要な違いについて列挙する。

チャンクモデルとタスクレットモデルの比較
項目 チャンク タスクレット

構成要素

ItemReader, ItemProcessor, ItemWriterの3つに分割する。

Taskletの1つに集約する。

トランザクション

一定件数で中間コミットを発行しながら処理することが基本となる。一括コミットはできない。
処理対象データ件数に依らず一定のマシンリソースで処理できる。
処理途中でエラーが発生すると未処理データと処理済データが混在する。

全体で一括コミットにて処理することが基本となる。中間コミットはユーザにて実装する必要がある。
処理対象データが大量になると、マシンリソースが枯渇する恐れがある。
処理途中でエラーが発生すると未処理データのみにロールバックされる。

リスタート

件数ベースのリスタートができる。

件数ベースのリスタートはできない。

これを踏まえて、以下にそれぞれを使い分ける例をいくつか紹介する。

リカバリを限りなくシンプルにしたい

エラーとなったジョブは対象のジョブをリランするのみで復旧したい場合など、 リカバリをシンプルにしたい時はタスクレットモデルを選択するとよい。
チャンクモデルでは処理済データをジョブ実行前の状態に戻したり、 未処理データのみ処理するようジョブを予め作りこんでおいたり、 といった対処が必要となる。

処理の内容をまとめたい

1ジョブ1クラスなど、ジョブの見通しを優先したい場合はタスクレットを選択するとよい。

大量のデータを安定して処理したい

1000万件など、一括処理するとリソースに影響する件数を対象とする際はチャンクモデルを活用するか検討するとよい。 これは中間コミットによって安定させることを意味する。 タスクレットモデルでも中間コミットを打つことが可能だが、チャンクモデルの方がシンプルな実装になる可能性がある。

エラー後の復旧は件数ベースリスタートとしたい

バッチウィンドウがシビアであり、エラーとなったデータ以降から再開したい場合に、 Spring Batchが提供する件数ベースリスタートを活用するときは、チャンクモデルを選択する必要がある。 これにより、個々のジョブでその仕組を作りこむ必要がなくなる。

チャンクモデルとタスクレットモデルは、併用することが基本である。
バッチシステム内のジョブすべてをどちらかのモデルでのみ実装する必要はない。
システム全体のジョブがもつ特性を踏まえて、一方のモデルを基本とし、状況に応じてもう一方のモデルを使うことは自然である。

たとえば、大部分は処理件数や処理時間に余裕があるならばタスクレットモデルを基本とし、 極少数の大量件数を処理するジョブはチャンクモデルを選択する、といったことは自然といえる。