WebOTX Batch Serverではジョブを実行するために必要な内部リソースの設定をバッチドメインエージェントで管理します。
バッチドメインエージェントを経由して各種設定の変更や、アカウントやアプリケーション毎の設定を行うことができます。
本機能を利用することで、ジョブが実行時に利用するリソースと、基盤として提供するリソースの依存関係を分離し、最小限のアプリケーションの修正でジョブ実行環境の変更や移行が可能になります。
Batch Serverによってジョブを実行する場合、ジョブを実行したアカウント名、バッチアプリケーショングループ名、バッチアプリケーション名、ジョブ名の４つのパラメータを指定します。
この４つの値の組合せのことを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名でバインドするのかを定義したジョブ実行リソースコンテキストをジョブリクエストパスに応じて定義します。
ジョブ実行リソースコンテキストは下記のようなジョブリクエストパスの階層それぞれに定義することができます。
また、デフォルトのジョブ実行リソースコンテキストがあらかじめ定義されています。
ジョブ実行リソースコンテキストは、ジョブを実行する際に指定されたアカウント名、バッチアプリケーショングループ名、バッチアプリケーション名から対応するコンテキストを選択して実行時に決定されます。
実行時に該当するジョブ実行リソースコンテキストが無い場合に、デフォルトのジョブ実行リソースコンテキストが利用されます。
アカウントやバッチアプリケーション毎の設定が不要な場合や、既定値の設定として必要な定義をしてください。
アカウント名、バッチアプリケーショングループ名、バッチアプリケーション名の指定にはワイルドカードとして_ANY_を指定することができます。 デフォルトのジョブ実行リソースコンテキストは、アカウントの階層に定義された_ANY_指定のジョブ実行リソースコンテキストです。
ジョブ実行リソースコンテキストは、ジョブリクエストパスを指定して登録します。
例えば、"userA/batchApGroup1"と、"userA/_ANY_/batchAp2"というジョブリクエストパスを指定してジョブ実行リソースコンテキストを追加すると、下記のようなツリーが構成されます。
このとき、batchApgGroup1とbatchAp2という葉ノードにのみジョブ実行リソースコンテキストが存在し、ジョブ実行リソースコンテキストが存在するノードに対してのみ設定を行うことができます。
ジョブ実行リソースコンテキストの検索は、以下のような手順で行われます。
例えば、上記の設定時に、
"userA/batchApGroup1/batchAp2"というジョブリクエストパスのジョブ実行要求があると、
"userA/batchApGroup1"に登録したジョブ実行リソースコンテキストが利用されます。
一方、"userA/batchApGroupX/batchAp2"というジョブリクエストパスのジョブ実行要求があると、
"userA/_ANY_/batchAp2"に登録したジョブ実行リソースコンテキストが利用されます。
ただし、"userA/batchApGroup1/batchAp3"というジョブリクエストパスのジョブ実行要求があると、 手順 1で解決されたノードが"userA/_ANY_"となり、このパス上にジョブ実行リソースコンテキストが存在しないため、 デフォルトのジョブ実行リソースコンテキストが利用されます。
バッチコンテナプロセスにはデフォルトのWorkManagerが１つだけ設定されています。このコンテナプロセスデフォルトのWorkManagerは全てのジョブリクエストパスに対して共通で利用されるため、アカウント毎やジョブ毎に特別なスレッドを用意することができません。
そこで、Batch Serverではジョブ実行リソース用のWorkManagerの設定をJobExecutionResouceManagerで一括管理し、ジョブ実行リソースコンテキスト毎に必要なWorkManagerを選択します。そうすることで、バッチコンテナプロセスが用意するデフォルトのWorkManagerとは異なるWorkManagerを利用してジョブ内の一部の処理を個別のスレッド上で動作させることが可能です。
ジョブ実行リソース用のWorkManagerを利用するには、
ジョブ実行リソースコンテキスト毎に設定可能な項目は下記のとおりです。
Batch Serverでは、全てのJDBCデータソースをJNDIサービスに登録し、JNDI名を指定してJNDIサービスから利用するJDBCデータソースを取得します。このとき、Spring Batchで定義するジョブからはデータソースを指定するBeanとしてそのBean名が必要になります。
Batch ServerはこのJNDI名とBean名のマッピングをジョブ実行リソースコンテキスト毎に管理しています。
以下の例のようなマッピングをコンテキスト毎に定義することで、ジョブの定義を変更することなくユーザが扱うデーターベースを変更する（ユーザ毎に扱うデータを変更する）ことができます。
| Bean名 | JDBCデータソースのJNDI名 |
|---|---|
| dataSource1 | jdbc/DS1 |
| dataSource2 | jdbc/DS2 |
| Bean名 | JDBCデータソースのJNDI名 |
|---|---|
| dataSource1 | jdbc/DS3 |
| dataSource2 | jdbc/DS4 |
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 |
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 |
各コンテナプロセスにはあらかじめWorkManagerが存在しており、通常はそのWorkManagerが管理するスレッドを利用してジョブを実行しています。
ジョブ実行リソースコンテキスト毎に利用するWorkManagerのBean名とWorkManager名のマッピングを指定します。
| Bean名 | WorkManager名 |
|---|---|
| workManager1 | threadPool1 |
| workManager2 | threadPool2 |
リソースコンテキスト毎にジョブ実行ログのログレベルを変更することができます。
リソースコンテキスト毎の ジョブ実行ログレベル に応じたメッセージが、ジョブ実行ログ(%{DOMAIN_HOME}/logs/<アカウント名>/<バッチアプリケーショングループ名>/<バッチアプリケーション名>/<ジョブ名>/<ジョブ名>_${JOB_INSTANCE_ID}.log)、および、ジョブ実行コマンドの標準出力に出力されます。
ドメインセットアップ時に設定されるデフォルトのジョブ実行リソースコンテキストには、あらかじめ下記の設定がされています。
| Bean名 | JDBCデータソースのJNDI名 |
|---|---|
| dataSource | jdbc/default |
ジョブ実行リソースコンテキストはジョブを実行時にバッチコンテナプロセス内で初期化されます。
一度初期化されたジョブ実行リソースコンテキストは、ジョブ実行リソースコンテキストのキャッシュの設定に応じて、ジョブの実行毎に生成するか、コンテキストの設定が修正されない限り以降そのコンテキストを共有・再利用さるかが選択できます。
既定値では、キャッシュの設定は無効化されているため、ジョブが実行されるたびにコンテキストを生成します。
ドメインエージェント上でのジョブ実行リソース毎の設定は、ジョブ実行リソースコンテキストが生成されるタイミングで反映されます。
キャッシュを有効にしている場合、ジョブ実行リソース毎の設定を変更後に新たなジョブを実行すると、キャッシュされているコンテキストは利用せずに、新たな設定を利用したコンテキストが再生成されます。
ジョブ実行リソースコンテキスト、および、ジョブ実行リソースコンテキストを親のコンテキストに持つバッチアプリケーションのコンテキストはGCのタイミングで回収・破棄されます。
ジョブ実行リソースコンテキストのキャッシュが有効な場合、キャッシュされている最新のジョブ実行リソースコンテキストをメモリ中に保持します。キャッシュの保持はジョブ実行リソースコンテキスト毎に行うので、最大でもジョブ実行リソースコンテキストを定義した数だけメモリ中に保持する可能性があります。
JDBCデータソースをルックアップするタイミングは、下記の順で実施されるそれぞれの初期化タイミングにより決まります。
スコープがsingletonの場合、ジョブ実行リソースが生成されるタイミングでデータソースBeanファクトリを生成し、 そのジョブ実行リソースコンテキスト内で再利用します。
スコープをprototypeにした場合、データソースBeanを必要とするタイミング（通常はジョブの初期化時）に
データソースBeanファクトリを生成します。
ジョブ内でデータソースBeanをコンテキストから明示的に取得する(getBean()を呼び出す)ような実装の場合には、
データソースBeanを取得する度にデータソースBeanファクトリを生成します。
データソースBeanファクトリが初期化されるタイミングでJNDIサービスからのルックアップを実行します。
一度JNDIサービスからルックアップしたデータソースオブジェクトを再利用します。
データソースオブジェクトのキャッシュを無効化した場合や、データソースBeanのスコープをprototypeにした場合、
１つのトランザクション内で異なるデータソース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サービスからルックアップする処理が頻発するよう設定すると、
ジョブの実行性能に大きな影響を与えるため、耐障害性・使用性とジョブの性能を考慮して注意深く設定を変更してください。
Spring Batchが提供するリトライ機能を利用する場合、ジョブリポジトリ用のDBへの書込みに失敗した場合にリトライせずに即時終了する動作となります。これはSpring Batchの仕様となります。 また、Spring Batchでは、ジョブリポジトリ用のDBと業務用DBを別のDBに設定している場合、業務用DBのダウンのみであればリトライすることは可能です。 ただし、その場合、それぞれの更新処理が別トランザクションとなるため、チェックポイントデータの一貫性が損なわれる可能性があります。 WebOTX Batch Server V8.4から提供されるXA対応機能を利用したチェックポイントデータの一貫性保証と、本機能を併用することで、ジョブリポジトリ用DBおよび、業務用のDBのいずれのDBがダウンした場合のリトライとデータの一貫性保証を両立させることができます。
Spring Batchのジョブステップ実行中に、DB障害に起因した例外が発生した場合、DB接続の復旧を待機した後に、異常終了したジョブステップを再実行するための機能です。 本機能は以下のような動作をします。
バッチアプリケーション開発者は、ジョブ定義ファイル内に下記のような定義をすることで、本機能を利用することができます。 下記の定義追加・変更によってジョブステップに対して本機能を組み込みます。
下記のように、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は、一つのインスタンスをバッチアプリケーション内で共有することも可能です。また、一つのジョブ定義内に複数定義することも可能です。
次に、下記に示すように、本機能を利用したいジョブステップの定義に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の呼び出しはリスナに対して、下記のような順序付けをおこないます。
下記のように、リスナを追加したジョブステップの定義に対してステップ再実行用の定義を追加します。
<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を利用してステップのフローを設定します。
| ExitStatus | 説明 |
|---|---|
| SHOULD_RETRY | DBへの正常性確認が正常に完了した場合 |
| RETRY_OVER | retryLimitに指定された回数以内にDBの正常性が確認できなかった場合 |
| COULD_NOT_RETRY | ステップ内で発生した例外の中に、リトライ不可能な例外(トランザクション例外等)が含まれる場合 |
| プロパティ名 | 既定値 | 指定可能範囲 | 説明 |
|---|---|---|---|
| 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。空文字が指定されている場合は何も実行しません。 |
| プロパティ名 | 説明 |
|---|---|
| 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が指定されます。 |
Spring Batchが提供する以下のItemReader、および、ItemWriterは 本機能によってステップが再実行した場合も正しく動作することが確認されています。
Batch Serverがジョブを実行・状態参照する際にジョブリポジトリ用のDBにアクセスする部分をリトライするための機能です。 本機能はデフォルトでは無効化されています。 本機能を有効にした場合、ジョブの状態参照コマンド等のジョブ実行要求以外の操作もリトライの対象となります。本機能を有効化している状態でのJobRepository用のDBを意図的に停止させる場合、その間ジョブに関連する操作が待機させられる点に注意してください。
ジョブ実行リソースコンテキストMOのjobRepositoryRetryEnabled属性にtrueを設定することで本機能を有効にします。 ジョブ実行リソースコンテキストMOには以下の4種あります。
種別ごとのジョブ実行リソースコンテキストMO CLIName：domain.bssystem.job-execution-resource.execution-context.(各種別)
| プロパティ名 | 既定値 | 指定可能範囲 | 説明 |
|---|---|---|---|
| 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も合わせて設定してください。 |