ジョブ実行リソース

概要

WebOTX Batch Serverではジョブを実行するために必要な内部リソースの設定をバッチドメインエージェントで管理します。
バッチドメインエージェントを経由して各種設定の変更や、アカウントやアプリケーション毎の設定を行うことができます。

本機能を利用することで、ジョブが実行時に利用するリソースと、基盤として提供するリソースの依存関係を分離し、最小限のアプリケーションの修正でジョブ実行環境の変更や移行が可能になります。

ジョブリクエストパス

Batch Serverによってジョブを実行する場合、ジョブを実行したアカウント名、バッチアプリケーショングループ名、バッチアプリケーション名、ジョブ名の4つのパラメータを指定します。

この4つの値の組合せのことをBatch Serverではジョブリクエストパスと呼びます。 ジョブリクエストパスを使ってどのユーザがどのジョブを実行したか・しようとしているのかを判別しています。
また、Batch Serverではこのジョブリクエストパスの表記方法を下記のように定めます。

<アカウント名>/<バッチアプリケーショングループ名>/<バッチアプリケーション名>/<ジョブ名>

このジョブリクエストパスは用途に応じて、アカウント名部分を省略したり、ジョブ名を省略して表記したりします。

Batch Serverではこのジョブリクエストパスに応じて、ジョブ実行時に必要なリソースをSpring Batchのバッチアプリケーションが利用するBeanの定義として適切にバインドする機能を提供します。

ジョブ実行リソース

JobExecutionResourceManagerによって、実行環境で提供するデータソースやスレッドプール等ジョブを実行する上で必要なリソースをジョブ実行リソースコンテキストとして、Spring Batch / Spring FrameworkのBeanとしてマッピングします。
例えば、図2-1のようにバッチアプリケーションやジョブリポジトリが参照する"dataSource1"という名前のBeanにJNDIサーバに登録されているデータソース1をバインドすることができます。
こうすることで、バッチアプリケーションは"dataSource1"という名前のJDBCデータソースがJNDIサーバ上に登録されていることや、そのJNDI名を意識することなく利用できます。

ジョブ実行リソースコンテキスト

Batch Serverによって、設定構築したジョブ実行リソースコンテキストを元にSpring Batchを利用してジョブを実行します。このジョブ実行リソースコンテキストには、例えばJDBCデータソースのような、ジョブ実行に必要なリソースを適切なSpring FrameworkのBeanにマッピングしており、バッチアプリケーション開発者からは透過的(データソース名の違いや、設定の違いを意識することなく)に扱えるようにしています。

どのアプリケーションに対して、どのリソースをバインドするか、どのようなBean名でバインドするのかを定義したジョブ実行リソースコンテキストをジョブリクエストパスに応じて定義します。

関連

1. ジョブ実行リソースコンテキストの管理

ジョブ実行リソースコンテキストは下記のようなジョブリクエストパスの階層それぞれに定義することができます。

また、デフォルトのジョブ実行リソースコンテキストがあらかじめ定義されています。

ジョブ実行リソースコンテキストは、ジョブを実行する際に指定されたアカウント名、バッチアプリケーショングループ名、バッチアプリケーション名から対応するコンテキストを選択して実行時に決定されます。
実行時に該当するジョブ実行リソースコンテキストが無い場合に、デフォルトのジョブ実行リソースコンテキストが利用されます。 アカウントやバッチアプリケーション毎の設定が不要な場合や、既定値の設定として必要な定義をしてください。

アカウント名、バッチアプリケーショングループ名、バッチアプリケーション名の指定にはワイルドカードとして_ANY_を指定することができます。 デフォルトのジョブ実行リソースコンテキストは、アカウントの階層に定義された_ANY_指定のジョブ実行リソースコンテキストです。

ジョブ実行リソースコンテキストは、ジョブリクエストパスを指定して登録します。
例えば、"userA/batchApGroup1"と、"userA/_ANY_/batchAp2"というジョブリクエストパスを指定してジョブ実行リソースコンテキストを追加すると、下記のようなツリーが構成されます。
このとき、batchApgGroup1batchAp2という葉ノードにのみジョブ実行リソースコンテキストが存在し、ジョブ実行リソースコンテキストが存在するノードに対してのみ設定を行うことができます。

ジョブ実行リソースコンテキストの検索は、以下のような手順で行われます。

  1. 親のノードから順に検索し、ジョブリクエストパスと最も適合するジョブ実行リソースコンテキストのノードを決定
  2. そのノードへのパス内に存在するジョブ実行リソースコンテキストを決定
  3. そのノードへのパス内にジョブ実行リソースコンテキストが存在しない場合にデフォルトのジョブ実行リソースコンテキストを利用

例えば、上記の設定時に、 "userA/batchApGroup1/batchAp2"というジョブリクエストパスのジョブ実行要求があると、 "userA/batchApGroup1"に登録したジョブ実行リソースコンテキストが利用されます。
一方、"userA/batchApGroupX/batchAp2"というジョブリクエストパスのジョブ実行要求があると、 "userA/_ANY_/batchAp2"に登録したジョブ実行リソースコンテキストが利用されます。

ただし、"userA/batchApGroup1/batchAp3"というジョブリクエストパスのジョブ実行要求があると、 手順 1で解決されたノードが"userA/_ANY_"となり、このパス上にジョブ実行リソースコンテキストが存在しないため、 デフォルトのジョブ実行リソースコンテキストが利用されます。

関連

2. ジョブ実行リソース用WorkManagerの管理

バッチコンテナプロセスにはデフォルトのWorkManagerが1つだけ設定されています。このコンテナプロセスデフォルトのWorkManagerは全てのジョブリクエストパスに対して共通で利用されるため、アカウント毎やジョブ毎に特別なスレッドを用意することができません。

そこで、Batch Serverではジョブ実行リソース用のWorkManagerの設定をJobExecutionResouceManagerで一括管理し、ジョブ実行リソースコンテキスト毎に必要なWorkManagerを選択します。そうすることで、バッチコンテナプロセスが用意するデフォルトのWorkManagerとは異なるWorkManagerを利用してジョブ内の一部の処理を個別のスレッド上で動作させることが可能です。

ジョブ実行リソース用のWorkManagerを利用するには、

を行います。

関連

3. ジョブ実行リソースコンテキスト階層毎の設定

ジョブ実行リソースコンテキスト毎に設定可能な項目は下記のとおりです。

関連

3.1. データソースのJNDI名とBean名へのマッピング

Batch Serverでは、全てのJDBCデータソースをJNDIサービスに登録し、JNDI名を指定してJNDIサービスから利用するJDBCデータソースを取得します。このとき、Spring Batchで定義するジョブからはデータソースを指定するBeanとしてそのBean名が必要になります。
Batch ServerはこのJNDI名とBean名のマッピングをジョブ実行リソースコンテキスト毎に管理しています。

以下の例のようなマッピングをコンテキスト毎に定義することで、ジョブの定義を変更することなくユーザが扱うデーターベースを変更する(ユーザ毎に扱うデータを変更する)ことができます。

コンテキスト1(userA) の例
Bean名 JDBCデータソースのJNDI名
dataSource1 jdbc/DS1
dataSource2 jdbc/DS2
コンテキスト2(userB) の例
Bean名 JDBCデータソースのJNDI名
dataSource1 jdbc/DS3
dataSource2 jdbc/DS4

3.2. コンテキスト毎のジョブリポジトリの設定

Batch Serverではジョブ実行リソースコンテキスト毎に利用するジョブリポジトリを指定することができます。
つまり、アカウント毎にジョブリポジトリに利用するDBを分離したり、あるアカウントが実行するバッチアプリケーションのみジョブリポジトリに利用するDBを変更したりすることができます。

ジョブリポジトリへのアクセスに利用するデータソースのBean名を指定します。
指定するBeanはデータソースのJNDI名とBean名へのマッピングで定義したデータソースのBean名を指定する必要があります。

属性名
[attribute-name]
説明 既定値
ジョブリポジトリに利用するデータソースBean名
[jobRepositoryDataSourceBeanName]
ジョブ実行リソースコンテキストに割り当てられた、データソースのBean名とJNDI名へのマッピングの中から、ジョブリポジトリ用に利用するデータソースのBean名を指定します。 dataSource
データベースタイプ
[jobRepositoryDatabaseType]
ジョブリポジトリ用に利用するデータベースの種別を指定します。
ORACLE, POSTGRES, DERBY
を指定できます。
指定が無い場合、データベース接続時に自動判別を行います。
無し
CREATE実行用の分離レベル
[jobRepositoryIsolationLevelForCreate]
ジョブリポジトリに対して、ジョブ実行データを初期化するSQLを実行するトランザクションの分離レベルです。ステップ、および、タスクレット内で実行されるトランザクションには影響を与えません。 ISOLATION_READ_COMMITTED
VARCHARの最大長
[jobRepositoryMaxVarCharLength]
ジョブリポジトリに格納するジョブ実行データ用のVARCHARの最大長を指定します。この値を超える長さのデータをジョブリポジトリに格納する場合、指定した長さに丸められた情報がジョブリポジトリに格納されます。 2500
テーブル名プレフィックス
[jobRepositoryTablePrefix]
ジョブリポジトリ用のテーブル作成時にプレフィックスを指定している場合、そのプレフィックスを指定します。 無し
トランザクション状態の検証
[jobRepositoryValidateTransactionState]
ジョブリポジトリへのデータ更新時にトランザクションの状態をチェックするかどうかを指定します true
マップジョブリポジトリを利用
[usingMapJobRepository]
ジョブリポジトリにデータベースを利用せず、永続化されないメモリ上のジョブリポジトリを利用する場合に指定します。
trueを指定した場合、上記全ての設定値は無視されます。
false
関連

3.3. コンテキスト毎のトランザクションマネージャ の設定

Batch ServerではWebOTXが提供するTransactionサービスに接続するトランザクションマネージャのBeanをジョブ実行リソースコンテキストにマッピングしています。
このトランザクションマネージャはSpringが提供するJtaTransactionManagerを利用しており、このBeanに対する設定をジョブ実行リソースコンテキスト毎に指定することができます。

属性名
[attribute-name]
説明 既定値
デフォルトタイムアウト
[transactionManagerDefaultTimeout]
トランザクションを実行するクライアント側で指定するタイムアウト時間(秒)です。デフォルトの-1を指定すると、トランザクションサービス側で設定されているタイムアウト値が有効になります。 -1
failEarlyOnGlobalRollbackOnly グローバルトランザクションがrollback-onlyに設定されたことを検知した時点で早期に例外を発生させます。 false
globalRollbackOnParticipationFailure 一部のトランザクション失敗時にグローバルトランザクションをrollback-onlyに設定します。 true
rollbackOnCommitFailure commit失敗時のrollback呼び出しを行うかどうか選択します。 false
transactionSynchronization スレッドの境界に基づいた同期 SYNCHRONIZATION_ALWAYS
validateExistingTransaction 既存トランザクションの検証 false
関連

3.4. コンテキスト毎のWorkManagerの設定

各コンテナプロセスにはあらかじめWorkManagerが存在しており、通常はそのWorkManagerが管理するスレッドを利用してジョブを実行しています。
ジョブ実行リソースコンテキスト毎に利用するWorkManagerのBean名とWorkManager名のマッピングを指定します。

WorkManagerのBean名とWorkManager名のマッピングの例
Bean名 WorkManager名
workManager1 threadPool1
workManager2 threadPool2

3.5. コンテキスト毎のジョブ実行ログレベル

リソースコンテキスト毎にジョブ実行ログのログレベルを変更することができます。

リソースコンテキスト毎の ジョブ実行ログレベル に応じたメッセージが、ジョブ実行ログ(%{DOMAIN_HOME}/logs/<アカウント名>/<バッチアプリケーショングループ名>/<バッチアプリケーション名>/<ジョブ名>/<ジョブ名>_${JOB_INSTANCE_ID}.log)、および、ジョブ実行コマンドの標準出力に出力されます。

参照

3.6. デフォルトジョブ実行リソースコンテキスト

ドメインセットアップ時に設定されるデフォルトのジョブ実行リソースコンテキストには、あらかじめ下記の設定がされています。

データソースのJNDI名とBean名のマッピング
Bean名 JDBCデータソースのJNDI名
dataSource jdbc/default
ジョブリポジトリ用のデータソースBean名
Bean名=dataSource
トランザクションマネージャの設定
全て既定値
WorkManager
なし
ジョブ実行ログレベル
INFO

4. ジョブ実行リソースコンテキストのライフサイクル

ジョブ実行リソースコンテキストの生成と破棄

ジョブ実行リソースコンテキストはジョブを実行時にバッチコンテナプロセス内で初期化されます。
一度初期化されたジョブ実行リソースコンテキストは、ジョブ実行リソースコンテキストのキャッシュの設定に応じて、ジョブの実行毎に生成するか、コンテキストの設定が修正されない限り以降そのコンテキストを共有・再利用さるかが選択できます。
既定値では、キャッシュの設定は無効化されているため、ジョブが実行されるたびにコンテキストを生成します。

ドメインエージェント上でのジョブ実行リソース毎の設定は、ジョブ実行リソースコンテキストが生成されるタイミングで反映されます。
キャッシュを有効にしている場合、ジョブ実行リソース毎の設定を変更後に新たなジョブを実行すると、キャッシュされているコンテキストは利用せずに、新たな設定を利用したコンテキストが再生成されます。

ジョブ実行リソースコンテキスト、および、ジョブ実行リソースコンテキストを親のコンテキストに持つバッチアプリケーションのコンテキストはGCのタイミングで回収・破棄されます。
ジョブ実行リソースコンテキストのキャッシュが有効な場合、キャッシュされている最新のジョブ実行リソースコンテキストをメモリ中に保持します。キャッシュの保持はジョブ実行リソースコンテキスト毎に行うので、最大でもジョブ実行リソースコンテキストを定義した数だけメモリ中に保持する可能性があります。

ジョブ実行リソースコンテキストとJDBCデータソースのルックアップ

JDBCデータソースをルックアップするタイミングは、下記の順で実施されるそれぞれの初期化タイミングにより決まります。

  1. ジョブ実行リソースコンテキストの生成
    ジョブ実行リソースコンテキストのキャッシュ設定が影響
  2. データソースBeanファクトリの生成
    データソースBeanのスコープの設定が影響
  3. JNDIサービスからのルックアップ
    データソースオブジェクトのキャッシュ
    および、
    Beanの初期化時にルックアップするかどうか
    が影響
ここでは、ジョブ実行リソースコンテキストにより生成するデータソースオブジェクトは、JNDIサービスからルックアップするタイミングを調整する下記設定値について説明します。

耐障害性・性能・使用性の考慮

データソースオブジェクトのキャッシュを無効化した場合や、データソースBeanのスコープをprototypeにした場合、 1つのトランザクション内で異なるデータソースBeanを複数扱う可能性があります。 そのような場合に、Spring Frameworkによるトランザクション内でのJDBC Connectionの再利用ができず、 同一の接続先データベースに異なる複数のコネクションからアクセスする事になります。 その結果、JTA連携を有効にしている場合にトランザクションがエラー終了してしまいます。
(この様な場合は、JDBCデータソースのuseOneConnectionPerTransactionをtrueに設定して同エラーを回避できます)

JNDIルックアップが実行される際に、ドメインエージェントプロセスがダウンしていると、 JNDIルックアップが失敗しジョブが異常終了します。
ドメインエージェントプロセスの障害の影響を極力減らすためには、

にすることで、極力データソースのルックアップをジョブの開始時のみにまとめることができます。

JDBC データソースに対する設定変更が反映されるタイミングはJNDIサービスからルックアップするタイミングです。
下記のような設定にすると、最初のジョブ実行リソースコンテキスト初期化時のJDBC データソース設定で動作し、 以降バッチコンテナを再起動するか、ジョブ実行リソースコンテキスト毎の設定を変更して新たなジョブを再実行するまで JDBC データソースの設定変更は反映されません。

JDBCデータソースをキャッシュしている場合、再起動したデータベースに接続するタイミングは、 JDBCデータソースの設定とその挙動に依存します。
また、ジョブ実行中にデータベースとの接続が切断された場合、Spring Frameworkによる 同一トランザクション内でのJDBC Connectionの再利用の機構により、トランザクションが終了するまでは、 同一のデータソースに対するgetConnection()の要求は発行されません。

上記のように、キャッシュの設定に応じてJDBCデータソースをJNDIサービスからルックアップするタイミングが変化します。
このJNDIサービスからルックアップする処理が頻発するよう設定すると、 ジョブの実行性能に大きな影響を与えるため、耐障害性・使用性とジョブの性能を考慮して注意深く設定を変更してください。

5. DB接続リトライ制御

Spring Batchが提供するリトライ機能を利用する場合、ジョブリポジトリ用のDBへの書込みに失敗した場合にリトライせずに即時終了する動作となります。これはSpring Batchの仕様となります。 また、Spring Batchでは、ジョブリポジトリ用のDBと業務用DBを別のDBに設定している場合、業務用DBのダウンのみであればリトライすることは可能です。 ただし、その場合、それぞれの更新処理が別トランザクションとなるため、チェックポイントデータの一貫性が損なわれる可能性があります。 WebOTX Batch Server V8.4から提供されるXA対応機能を利用したチェックポイントデータの一貫性保証と、本機能を併用することで、ジョブリポジトリ用DBおよび、業務用のDBのいずれのDBがダウンした場合のリトライとデータの一貫性保証を両立させることができます。

WebOTX Batch Serverでは、上記の2つの機能を提供することで、ジョブリポジトリ用のDBや業務用DBがダウンした際に可能な限りジョブの実行を継続させることができます。 以降では、これら2つの機能、即ち、DB接続リトライステップリスナ機能とジョブリポジトリDB接続リトライ機能について、機能の説明や利用方法について説明します。

5.1. DB接続リトライステップリスナ機能

5.1.1. 機能の概要

Spring Batchのジョブステップ実行中に、DB障害に起因した例外が発生した場合、DB接続の復旧を待機した後に、異常終了したジョブステップを再実行するための機能です。 本機能は以下のような動作をします。

  1. DB接続リトライリスナを組み込んだジョブステップの実行中に発生した例外をハンドリング
  2. リトライ可能な例外である場合に、ジョブ実行リソースコンテキストとジョブのコンテキストに関連付けられている全てのJDBC DataSourceに対応するDBに対して、指定された間隔・上限回数に従って正常性を確認
  3. DBの正常性が確認できると、ジョブの定義に従ってジョブステップを再実行
本機能によって、ジョブステップを再実行するかどうかはジョブの定義に依存します。以降の利用方法を参照し、ジョブ定義を行ってください。

5.1.2. 機能の利用方法

バッチアプリケーション開発者は、ジョブ定義ファイル内に下記のような定義をすることで、本機能を利用することができます。 下記の定義追加・変更によってジョブステップに対して本機能を組み込みます。

  1. DB接続リトライ ステップリスナのBean定義
  2. 組み込み対象のジョブステップの定義にリスナを登録
  3. ステップリスナによるDB正常性確認後にエラーが発生したステップを再実行するよう定義

1. DB接続リトライステップリスナのBean定義

下記のように、DB接続リトライステップリスナBean定義をジョブ定義ファイルに記述します。

<bean id="dbRetryStepListener"
      class="com.nec.webotx.batch.util.BSDBRetryStepListener">
    <property name="retryLimit" value="15"/>
    <property name="retryInterval" value="60000"/>
    <property name="retryableExceptionClasses">
        <list>
            <value>org.springframework.jdbc.CannotGetJdbcConnectionException</value>
            <value>org.springframework.dao.DataAccessResourceFailureException</value>
        </list>
    </property>
</bean>
上記で示されるBean中に指定するpropertyの詳細は5.1.3. 機能の利用方法を参照してください。 BSDBRetryStepListenerは、一つのインスタンスをバッチアプリケーション内で共有することも可能です。また、一つのジョブ定義内に複数定義することも可能です。

2. 対象となるジョブステップの定義にリスナを登録

次に、下記に示すように、本機能を利用したいジョブステップの定義にDB接続リトライステップリスナを追加します。下記の太字の部分が追加する内容です。

<b:job id="db2db" restartable="true">
    <b:step id="simpleStep">
        <b:tasklet>
            <b:chunk reader="dbReader" processor="processor" writer="dbWriter" commit-interval="5"/>
            <b:listeners>
                <b:listener ref="dbRetryStepListener"/>
            </b:listeners>
        </b:tasklet>
    </b:step>
</b:job>
com.nec.webotx.batch.util.BSDBRetryStepListenerはOrderedインタフェースを実装しています。 Spring BatchによるStepExecutionListenerの呼び出しはリスナに対して、下記のような順序付けをおこないます。
  1. Ordered#getOrder()が返す値による順序(値が小さいほうが先)で並べ替えたリスナ
  2. 次に、listenersに指定した順番のリスナ。(親の定義から継承してmergeした場合は、親の定義で指定したものが先)
この順序に従ってStepExecutionListener#beforeStep()を呼び出します。また、この順序とは逆順にStepEexecutionListener#afterStep()を呼び出します。 他のStepExecutionListenerも同時に登録する場合は、上記の順番に注意してください。

3. ステップリスナによるDB正常性確認後にエラーが発生したステップを再実行するよう定義

下記のように、リスナを追加したジョブステップの定義に対してステップ再実行用の定義を追加します。

<b:job id="db2db" restartable="true">
    <b:step id="simpleStep">
        <b:tasklet>
            <b:chunk reader="dbReader" processor="processor" writer="dbWriter" commit-interval="5"/>
            <b:listeners>
                <b:listener ref="dbRetryStepListener"/>
                <b:listener ref="bsForceStopListener"/>
            </b:listeners>
        </b:tasklet>
        <b:next on="SHOULD_RETRY" to="simpleStep"/>
        <b:fail on="RETRY_OVER"/>
        <b:fail on="COULD_NOT_RETRY"/>
        <b:end on="*"/>
    </b:step>
</b:job>
DB接続リトライ ステップリスナはDB接続確認の結果に応じて下記のExitStatusを返却します。 これらのExitStatusを利用してステップのフローを設定します。
表5.1.2.1
ExitStatus 説明
SHOULD_RETRY DBへの正常性確認が正常に完了した場合
RETRY_OVER retryLimitに指定された回数以内にDBの正常性が確認できなかった場合
COULD_NOT_RETRY ステップ内で発生した例外の中に、リトライ不可能な例外(トランザクション例外等)が含まれる場合
これらの、ExitStatusはリスナの拡張プロパティによって変更することも可能です。 上記設定例のように、RETRY_OVERやCOULD_NOT_RETRYのステータスで異常終了させるよう定義した場合、BatchStatus=FAILED, ExitStatus=RETRY_OVER(またはCOULD_NOT_RETRY)でジョブが終了します。 デフォルトのExitCodeマッピング設定ファイルを利用すると、ジョブを実行していたコマンドは終了コード=1で終了します。 ExitCodeマッピング設定ファイルを適切に修正することで、RETRY_OVERの発生やCOULD_NOT_RETRYの発生を終了コードから判定することも可能です。

5.1.3. 機能の利用方法

基本プロパティ
以下は利用者の要件に応じて既定値を変更して利用します。
表5.1.3.1
プロパティ名 既定値 指定可能範囲 説明
retryLimit 0 0 - Integer.MAX_VALUE DB障害時の接続確認上限。指定された回数分DBへの接続に失敗すると、RETRY_OVERで返却して終了します。
retryInterval 60000 0 - Long.MAX_VALUE DB障害時の接続確認間隔 (ミリ秒)
retryableExceptionClasses org.springframework.dao.
DataAccessResourceFailureException
ロード可能な例外クラス一覧 リトライ可能例外のリスト
validationQuery commit SQL文 DB接続の正常性を確認するためのSQL。空文字が指定されている場合は何も実行しません。
拡張プロパティ
以下は利用者によってリスナの動作をカスタマイズするためのものです。 通常指定する必要はありません。
表5.1.3.2
プロパティ名 説明
retryableExceptionClassifier どの例外がリトライ可能な例外であるかを判定するClassifierを指定します。Classifier<Throwable, Boolean>の実装を指定します。 既定値は、retryableExceptionClassesに指定された例外で、WebOTX Batch Serverが既定するリトライ不可能な例外でない場合にリトライ可能と判定する実装が設定されます。
shouldRetryStatus ステップを再実行可能な場合に返却するExitStatusを指定します。既定値は"SHOULD_RETRY"です。空文字を指定した場合には定義エラーとなります。
retryOverStatus DB接続リトライに失敗した場合に返却するExitStatusを指定します。既定値は"RETRY_OVER"です。空文字を指定した場合には定義エラーとなります。
couldNotRetryStatus ステップ内でトランザクション例外が発生し、ステップを再実行できない可能性に陥っておりリトライ不可能な場合に返却するExitStatusを指定します。デフォルトは"COLUD_NOT_RETRY"です。 空文字を指定した場合は、StepExecutionに設定されているExitStatusをそのまま返します。
backoffPolicy DB接続のリトライ間隔を調整するためのBackoffPolicyを指定します。既定値はretryIntervalに指定された秒数だけsleepするFixedBackOffPolicyが設定されます。
shouldRetryLimit SHOULD_RETRYによって再実行させる回数に制限を設けます。既定値は無効(=0)です。制限を超えている場合、StepExecutionに設定されているExitStatusをそのまま返します。
validatitonTargetIncludes デフォルトではジョブ実行リソースコンテキストとジョブのコンテキストに含まれるDataSourceインタフェースBean全てがDB接続の正常性確認対象になります。その対象のなかで正常性確認対象にするDataSourceのBean名を明示します。存在しないDataSourceのBean名を指定した場合、ジョブの初期化に失敗しジョブが異常終了します。
validatitonTargetExcludes デフォルトではジョブ実行リソースコンテキストとジョブのコンテキストに含まれるDataSourceインタフェースBean全てがDB接続の正常性確認対象になります。その対象のなかから除外するDataSourceのBean名を指定します。validatitonTargetIncludesと合わせて指定した場合、validatitonTargetIncludesで絞り込んだ正常性確認対象一覧の中から、validatitonTargetExcludesに指定されたものを除外します。
order StepExecutionListenerの順序を指定します。既定値は0が指定されます。

5.1.4. 本機能と組み合わせて動作可能なItemReaderとItemWriter

Spring Batchが提供する以下のItemReader、および、ItemWriterは 本機能によってステップが再実行した場合も正しく動作することが確認されています。

ItemReader
ItemWriter

5.2. ジョブリポジトリDB接続リトライ機能

5.2.1. 機能の概要

Batch Serverがジョブを実行・状態参照する際にジョブリポジトリ用のDBにアクセスする部分をリトライするための機能です。 本機能はデフォルトでは無効化されています。 本機能を有効にした場合、ジョブの状態参照コマンド等のジョブ実行要求以外の操作もリトライの対象となります。本機能を有効化している状態でのJobRepository用のDBを意図的に停止させる場合、その間ジョブに関連する操作が待機させられる点に注意してください。

5.2.2. 機能の利用方法

ジョブ実行リソースコンテキストMOのjobRepositoryRetryEnabled属性にtrueを設定することで本機能を有効にします。 ジョブ実行リソースコンテキストMOには以下の4種あります。

関連

5.2.3. 設定項目

種別ごとのジョブ実行リソースコンテキストMO CLIName:domain.bssystem.job-execution-resource.execution-context.(各種別)

表5.2.3.1
プロパティ名 既定値 指定可能範囲 説明
jobRepositoryRetryEnabled false true | false ジョブリポジトリDB接続リトライ機能を有効化します。
jobRepositoryRetryLimit 10 0 - Integer.MAX_VALUE DB障害時の接続確認上限回数指定された回数分DBへの接続に失敗するとリトライ動作に入る契機となった例外(JobRepositoryのメソッドがスローした例外)をスローします。
jobRepositoryRetryInterval 60 1 - 3600(1時間) DB障害時の接続確認間隔 (秒)
jobRepositoryRetryableExceptionClasses org.springframework.dao.
DataAccessResourceFailureException org.springframework.jdbc.support.
MetaDataAccessException
ロード可能な例外クラス一覧 リトライ可能例外のリスト
jobRepositoryCheckServerCommand commit SQL文 DB接続の正常性を確認するためのSQL指定が無い場合は何も実行しません。
jobRepositoryInvocationLimit 3 1 - Integer.MAX_VALUE DBの正常性確認後にJobRepositoryメソッド
jobRepositoryNotRetryOnJobInitialization true true | false ジョブ開始時の既存ジョブの確認とJobExecution生成にともなうアクセスをリトライするかどうか。
この設定をfalseにする場合、jobRepositoryDatabaseTypeも合わせて設定してください。