バッチ処理の概要
最終更新日: 2020年3月14日
R8 | R9
「バッチ処理」とは、ボタン押下または時間指定といったタイミングで、何らかの処理を行うことをいいます。ここでは、特にデータベース更新を伴うことを想定します。
開発者は、Wagbyで開発したアプリケーションのテーブル構造をすべて把握できます。モデル設計に基づいたテーブルスキーマも自動生成されるためです。そのため、別プログラムからテーブルを参照・更新することができます。この考え方に基づき、バッチ処理を実現する4つの方法を説明します。
「ストアドプロシージャ」または「(Java以外の)外部プログラム」でバッチ処理を実現する場合、ロックとキャッシュを考慮する必要があります。ここではロックについて説明します。
実現するバッチ処理が次の内容に該当する場合は、ロックを考慮する必要はありません。
上記以外の場合とは、Wagbyを利用しているユーザーがいる(更新を行うことがある)状態で、バッチ処理による更新も実行されるということです。この場合、データを適切にロックし、書き込みの競合を制御する必要があります。
Wagbyは楽観ロックと悲観ロックを選択できます。バッチ処理プログラムを作成する観点からは、次のような違いがあります。
一般に、バッチ処理プログラム作成という観点からは、楽観ロックの制御が難易度は低いです。Wagbyの標準は「悲観ロック」ですが、バッチ処理プログラムからも同時に更新されるモデルは、楽観ロックへ変更することを検討するとよいでしょう。
いずれの場合も、バッチ処理プログラムではロックの競合を検出した場合は更新・削除を抑制してください。これによってデータを安全に保つことができます。
Javaで作成する場合でも、Wagby が自動生成する Service クラスを使わず、直接 SQL を実行させるプログラムであれば、ロック制御は必要です。
Wagbyが自動生成するServiceクラスを再利用したプログラムとすると、ロック制御を省略できます。(これらはすべてServiceクラスが自動的に制御します。)この詳細は後述します。
Wagbyではデータベースから読み込んだ値をメモリ上にキャッシュとして保持しています。これによってSQL発生回数を減らし、アプリケーションのパフォーマンスを向上させています。
そのため「ストアドプロシージャ」または「(Java以外の)外部プログラム」でバッチ処理を実現する場合、更新を行なったモデルのキャッシュをクリアする必要があります。
外部プログラムから、キャッシュをクリアするREST APIを呼び出すことができます。この方法がもっとも簡単です。
Wagbyが自動生成するServiceクラスを再利用したプログラムとすると、キャッシュクリア処理を省略できます。(これらはすべてServiceクラスが自動的に制御します。)この詳細は後述します。
4つの実現方法
方式
特徴
考慮する点
ストアドプロシージャ型
データベース内で完結する。データベースが提供するトリガー機能や、スケジューラ機能も利用できる。(*)
JVM内に用意されたJavaオブジェクトを参照することはできない。Wagbyが提供するロックやキャッシュを当該バッチプログラムから制御する必要がある。
外部プログラム型
Java以外の言語を利用できる。例えば .NET や RPG で作成したプログラムを呼び出す。
Java
Wagbyが生成するJavaコードを再利用できる。
ジョブ実行制御は行わないとする。
Java (SpringBatch利用)
Wagbyが生成するJavaコードを再利用できる。
ジョブ実行制御はフレームワークが提供する。
SpringBatchの流儀を学ぶ必要がある。
ロック
楽観ロックと悲観ロック
ロック方式
楽観ロック
悲観ロック
実装方法
Wagbyが生成したテーブルに「バージョン管理用カラム」が含まれます。バッチ処理プログラムでは、読み込み時にこのカラムの値(数値)を記憶し、この値を where 句に加えて更新します。もし他の利用者がこのデータを更新していた場合はバージョン値が変わっているため、データの更新に失敗します。
Wagbyが提供するロックマネージャの挙動を変更します。通常、ロックオブジェクトはメモリ内で管理されますが、これを jfclockobject テーブルに書き込むようにします。バッチ処理プログラムでは、jfclockobject テーブルにロックキーが存在した場合は、更新を行わないようにします。
ワンポイント
Javaで作成する場合
キャッシュ
REST APIを使う
Serviceオブジェクトを使う