4.3. JSRに準拠したバッチアプリケーションとNablarchバッチアプリケーションとの機能比較

この章では、以下の機能の比較を示す。

機能比較(JSR:JSRの仕様で定義されている ○:提供あり △:一部提供あり ×:提供なし -:対象外)
機能 JSR352に準拠 [1] Nablarchバッチ
起動時に任意のパラメータを設定できる JSR
解説書へ
同一バッチアプリケーションの同時実行を防止できる
Javadocへ

解説書へ
実行中のバッチアプリケーションを
外部から安全に停止することができる
JSR
解説書へ
1回の実行で処理する最大の件数を指定できる ×
[2]

解説書へ
一定件数単位のコミットができる JSR
解説書へ
障害発生ポイントから再実行ができる JSR
[3]
業務処理を複数スレッドで並列実行できる JSR
解説書へ
特定の例外を無視して処理を継続することができる
(ロールバック後に処理を継続できる)
JSR ×
[4]
特定の例外発生時に処理をリトライできる JSR
[5]
バッチアプリケーションの結果を元に
次に実行する処理を切り替えられる
JSR ×
[6]
入力データソースを一定間隔で監視し
バッチを実行出来る
× [7]
解説書へ
[1]JSRの箇所は、JSR352で規定されている仕様に従う。 詳細は、 JSR352(外部サイト、英語) のSpecificationを参照すること。
[2]ItemReader の実装クラスに、1回の実行で読み込む最大件数を指定できるプロパティを持たせるなどで対応可能。
[3]ResumeDataReader (レジューム機能付き読み込み) を使用することで障害発生ポイントからの再実行が可能。 ただし、この機能はファイルを入力としている場合にのみ利用できる。それ以外のデータを入力とする場合には、アプリケーション側で設計及び実装が必要となる。
[4]特定例外を無視して処理を継続したい場合は、ハンドラを追加して対応すること。
[5]

リトライハンドラ でリトライ可能例外の場合にリトライすることはできるが、JSR352のように例外が発生したデータの単純なリトライを行うことはできない。 リトライハンドラ では、リトライ対象の例外を柔軟に指定することができない。

リトライハンドラ で要件を満たすことができない(例外が発生したデータの単純なリトライや柔軟に例外を指定したい)場合は、ハンドラを追加して対応すること。

[6]ジョブスケジューラなどで対応すること。例えば、終了コードを元に次に実行するジョブを切り替える等の対応が必要になる。
[7]JSR352に準拠したバッチアプリケーションでは、一定間隔で入力データソースを監視するようなバッチ処理を実現することができない。 このため、このようなバッチアプリケーションが必要となった場合は、 Nablarchバッチアプリケーションの常駐バッチ を使用して実現すること。