JP2016066333A - データベースのロック制御システム及び方法 - Google Patents

Abstract

【課題】テーブル側にバージョン情報を持たせることなく、楽観ロック方式を実現する。
【解決手段】検索時には、APサーバ14から独自ロックサーバ20に対象テーブル、レコード、ユーザの特定情報を伴う仮ロックの設定申請が送信され、独自ロックサーバ20は、メモリ上に対応の仮ロック情報が存在しない場合には仮ロック情報を新規登録すると共に、APサーバ14に通知し、存在する場合にはユーザIDを既存の仮ロック情報に追加すると共に、APサーバ14に通知し、仮ロック設定完了後、APサーバ14はDBサーバ22に該当レコードの抽出を依頼する。データ更新時には、APサーバ14から独自ロックサーバ20に対象テーブル、レコード、ユーザの特定情報を伴う本ロックの設定申請が送信され、独自ロックサーバ20はメモリ上に対応の仮ロック情報が存在する場合には仮ロック情報を本ロック情報に移行させると共に、APサーバ14に通知し、APサーバ14はDBサーバ22に該当レコードの更新を依頼する。
【選択図】図３

Description

この発明はデータベースのロック制御システム及び方法に係り、特に、データの参照時には排他制御を行わずに複数ユーザの同時利用を許容し、データの更新時にのみロックを掛けて排他制御を行う楽観ロック技術に関する。

データベースの排他制御方式として、データの参照時からロックを掛けて排他制御を行う悲観ロック方式と、データの参照時にはロックを掛けずに複数ユーザによる同時利用を許容しつつ、データの更新時にのみロックを掛けて排他制御を行う楽観ロック方式が存在している（非特許文献１及び２参照）。

悲観ロック方式の場合、画面上に表示されたデータは自分が更新するまで変わらないことが保証されるため、在庫管理システムのようにデータの参照中に値が変化すると困る業務には適しているが、その間、他のユーザは当該データを参照することができないため、参照中におけるデータの不変性がそれほど厳密に要求されない業務については、楽観ロック方式の方が適しているといえる。

この楽観ロック方式においては、図４に示すように、DBサーバ50のテーブルＺに「Version」のデータ項目（または「タイムスタンプ」のデータ項目）を設けておき、この「Version」の値を制御することによって、複数ユーザ間における排他性が担保される。
例えば、ユーザＢのクライアントと接続されたAPサーバ52から「ID=2」のデータの参照を求めるSQLが発行されると（Ｓ50）、DBサーバ50からAPサーバ52に対して「DEF」の値と「version=1」が返される（Ｓ52）。
また、この直後にユーザＡのクライアントと接続されたAPサーバ54から同じく「ID=2」のデータの参照を求めるSQLが発行された場合にも（Ｓ54）、DBサーバ12からAPサーバに対して「DEF」の値と「version=1」が返される（Ｓ56）。

つぎに、ユーザＡのAPサーバ54から「ID=2」の値を「DEF」から「JKL」に更新すると共に、そのバージョンを「version=1」から「version=2」に更新することを求めるSQLが発行されると（Ｓ58）、DBサーバ50は該当レコードの値を「JKL」に更新すると共に、そのバージョンを「２」に更新する（Ｓ60）。

ここで、ユーザＢのAPサーバ52から「ID=2」の値を「DEF」から「MNO」に更新すると共に、そのバージョンを「version=1」から「version=2」に更新することを求めるSQLが発行された場合（Ｓ62）、該当レコードのバージョンが一致しないことを理由に、DBサーバ50からAPサーバ52に対してNGが返される（Ｓ64）。

楽観的ロックでいいじゃんインターネットURL：http://blogs.msdn.com/b/aonishi/archive/2013/01/26/10388513.aspx 検索日：２０１４年９月１６日 楽観ロックと悲観ロックの違いインターネットURL：http://naiki.hatenablog.com/entry/2014/01/16/020635 検索日：２０１４年９月１６日

以上のように、楽観ロック方式による場合、データ参照時にはロックが掛からないため複数ユーザが同一データを同時に参照することができる一方、データ更新時には早い者勝ちでロックが掛けられ、排他性が確保されることとなる。

ただし、従来の楽観ロック方式の場合にはテーブル側に余計なバージョン情報を持たせる必要があるため、データの件数に応じてテーブル容量の肥大化という問題が生じることとなる。
また、各APサーバのアプリケーションプログラム側でデータのバージョン情報を一々意識する必要があり、実装が煩雑化するという問題も生じていた。

この発明は、このような現状を鑑みて案出されたものであり、テーブル側にバージョン情報を持たせることなく、従ってアプリケーションプログラム側がこれを意識する必要もなく、楽観ロック方式を実現できる技術の提供を目的としている。

上記の目的を達成するため、請求項１に記載したデータベースのロック制御システムは、ユーザの操作するクライアントと接続されたAPサーバと、当該APサーバと接続された独自ロックサーバ及びDBサーバを備えたシステムであって、上記APサーバは、データの検索処理に際しては、対象となるテーブル、レコード及びユーザの特定情報を伴う仮ロックの設定申請を上記独自ロックサーバに送信し、上記独自ロックサーバから仮ロック設定完了の通知があった場合には、上記DBサーバに対して該当レコードの抽出を依頼し、データの更新処理に際しては、対象となるテーブル、レコード及びユーザの特定情報を伴う本ロックの設定申請を上記独自ロックサーバに送信し、上記独自ロックサーバから本ロック設定完了の通知があった場合には、上記DBサーバに対して該当レコードの更新を依頼し、当該DBサーバから更新完了の通知が送信された場合には、上記独自ロックサーバに対して本ロックの解除申請を送信し、上記独自ロックサーバは、上記APサーバから仮ロックの設定申請が送信された場合に、対応のテーブル、レコードに関する仮ロック情報がメモリ上に存在しない場合には当該テーブル、レコード、ユーザの特定情報を伴う仮ロック情報をメモリ上に新規登録すると共に、当該APサーバに対して仮ロック設定完了の通知を送信し、仮ロック情報が存在する場合には当該ユーザの特定情報を既存の仮ロック情報に追加すると共に、当該APサーバに対して仮ロック設定完了の通知を送信し、また上記APサーバから本ロックの設定申請が送信された場合に、メモリ上に対応のテーブル、レコード、ユーザに関する仮ロック情報が存在する場合には当該仮ロック情報を本ロック情報に移行させると共に、本ロック設定完了の通知を上記APサーバに送信し、当該APサーバから本ロックの解除申請が送信された場合には対応の本ロック情報を削除することを特徴としている。

請求項２に記載したデータベースのロック制御システムは、請求項１のシステムであって、さらに上記独自ロックサーバが、上記APサーバから仮ロックの設定申請が送信された場合に、上記仮ロック情報の他に、メモリ上に対応のテーブル、レコードに関する本ロック情報が存在するか否かをチェックし、本ロック情報が存在する場合には、当該本ロック情報が削除されるまで一時待機し、本ロック情報削除後に当該テーブル、レコード、ユーザの特定情報を伴う仮ロック情報をメモリ上に新規登録すると共に、当該APサーバに対して仮ロック設定完了の通知を送信することを特徴としている。

請求項３に記載したデータベースのロック制御方法は、ユーザの操作するクライアントと接続されたAPサーバと、当該APサーバと接続された独自ロックサーバ及びDBサーバを備えたシステムにおいて、データの検索処理に際しては、上記APサーバから上記独自ロックサーバに対し、対象となるテーブル、レコード及びユーザの特定情報を伴う仮ロックの設定申請が送信され、これを受けた独自ロックサーバは、メモリ上に対応のテーブル、レコードに関する仮ロック情報が存在しない場合には当該テーブル、レコード、ユーザの特定情報を伴う仮ロック情報をメモリ上に新規登録すると共に、当該APサーバに対して仮ロック設定完了の通知を送信し、仮ロック情報が存在する場合には当該ユーザの特定情報を既存の仮ロック情報に追加すると共に、当該APサーバに対して仮ロック設定完了の通知を送信し、これを受けた上記APサーバは、上記DBサーバに対して該当レコードの抽出を依頼し、データの更新処理に際しては、上記APサーバから上記独自ロックサーバに対し、対象となるテーブル、レコード及びユーザの特定情報を伴う本ロックの設定申請が送信され、これを受けた独自ロックサーバは、メモリ上に対応のテーブル、レコード、ユーザに関する仮ロック情報が存在する場合には当該仮ロック情報を本ロック情報に移行させると共に、本ロック設定完了の通知をAPサーバに送信し、これを受けた上記APサーバは、上記DBサーバに対して該当レコードの更新を依頼すると共に、当該DBサーバから更新完了の通知が送信された場合には、上記独自ロックサーバに対して本ロックの解除申請を送信し、これを受けた独自ロックサーバは、対応の本ロック情報を削除することを特徴としている。

この発明に係るデータベースのロック制御システム及び方法にあっては、楽観ロック方式の実現に必要なロック情報が独自ロックサーバのメモリ上に設定され、これまでのようにDBサーバのテーブル側にバージョン情報を持たせる必要がないため、無駄なバージョン情報によってテーブル容量が肥大化することを抑えることができる。
また、APサーバのアプリケーションプログラムも、テーブル上に設けられたバージョン情報を意識する必要がなくなり、その構成を簡素化することができる。

図１は、この発明に係るデータベースのロック制御システム10の全体構成を示す図であり、ユーザＡのクライアント12と接続されたAPサーバ14と、ユーザＢのクライアント16と接続されたAPサーバ18と、各APサーバ14, 18と接続された独自ロックサーバ20と、DBサーバ22を備えている。

図２は、APサーバ14(18)の機能構成を示すブロック図であり、APサーバ14(18)は、検索処理部30と、更新処理部32と、ロック処理部34を備えている。
ここで検索処理部30及び更新処理部32は、APサーバ14(18)にセットアップされた業務用のアプリケーションプログラムに従い、APサーバ14(18)のCPUが必要な処理を実行することにより、実現される。
また、ロック処理部34は、APサーバ14(18)にセットアップされたミドルウェアに従い、APサーバ14(18)のCPUが必要な処理を実行することにより、実現される。

つぎに、図３のフローチャートに従い、このシステム10における処理手順を説明する。
まず、ユーザＡがクライアント12の画面上でテーブルＸに格納された「ID=2」のデータの参照をリクエストすると、APサーバ14のロック処理部34から独自ロックサーバ20に対して、仮ロックの設定を申請する電文「SHARE LOCK Key="TBLX_ID_2」が送信される（Ｓ10）。この電文には、ユーザＡのIDも付加されている。

これを受けた独自ロックサーバ20は、メモリ上のロック情報の有無をチェックし、テーブルＸのID=2についてロック情報が設定されていないことを確認した上で、仮ロック情報として「Key=TBLX_ID_2---User=UserA」をメモリ上に記録した後（Ｓ12）、仮ロック設定完了の電文をAPサーバ14に返信する（Ｓ14）。

これを受けたAPサーバ14の検索処理部30は、DBサーバ22に対し「SELECT FROM TBLX WHERE ID=2」のSQLを送信する（Ｓ16）。
この結果、DBサーバ22からAPサーバ14に対して「ID=2」の値である「DEF」が送信され（Ｓ18）、クライアント12の画面上に表示される。

つぎに、ユーザＢがクライアント16の画面上でテーブルＸに格納された「ID=2」のデータの参照をリクエストすると、APサーバ18のロック処理部34から独自ロックサーバ20に対して、仮ロックの設定を申請する電文「SHARE LOCK Key="TBLX_ID_2」とユーザＢのIDが送信される（Ｓ20）。

これを受けた独自ロックサーバ20は、メモリ上に記録されたロック情報をチェックし、同じテーブルＸのID=2に仮ロックが設定されていることを探知すると、当該仮ロック情報にユーザＢのIDを追記した上で（Ｓ22）、仮ロック設定完了の電文をAPサーバ18に返信する（Ｓ24）。

これを受けたAPサーバ18の検索処理部30は、DBサーバ22に対し「SELECT FROM TBLX WHERE ID=2」のSQLを送信する（Ｓ26）。
この結果、DBサーバ22からAPサーバ18に対して「ID=2」の値である「DEF」が送信され（Ｓ28）、クライアント16の画面上に表示される。

ここで、ユーザＢがクライアント16の画面上で「ID=2」のデータの値を「DEF」から「JKL」に更新するリクエストをすると、APサーバ18のロック処理部34から独自ロックサーバ20に対して、本ロックの設定を申請する電文「LOCK Key="TBLX_ID_2」が送信される（Ｓ30）。この電文には、ユーザＢのIDが付加されている。

これを受けた独自ロックサーバ20は、メモリ上に記録されたロック情報をチェックし、同じテーブルＸのID=2についてユーザＢの仮ロック情報が登録されていることを確認した上で、当該仮ロック情報に所定の識別符号を付与し、本ロック情報に変更する（Ｓ32）。
そして、独自ロックサーバ20からAPサーバ18に対して、本ロック設定完了の電文が送信される（Ｓ34）。

独自ロックサーバ20から本ロック設定完了の通知を受けたAPサーバ18の更新処理部32は、DBサーバ22に対し「UPDATE TBLX SET ATTR="JKL" WHERE ID=2」のSQLを送信する（Ｓ36）。
そして、DBサーバ22によってテーブルＸの更新が実行され（Ｓ38）、更新完了の通知が送信されると（Ｓ40）、APサーバ18のロック処理部34から独自ロックサーバ20に対して本ロック解除を申請する電文「UNLOCK Key="TBLX_ID_2"」が送信される（Ｓ42）。

これを受けた独自ロックサーバ20は、メモリ上に記録された「TBLX_ID_2」に係る本ロック情報を削除する（Ｓ44）。

この段階において、ユーザＡがクライアント12の画面上で「ID=2」の値を「DEF」から「LMN」に更新するリクエストを行い、APサーバ14のロック処理部34から独自ロックサーバ20に対して、本ロックの設定を申請する電文「LOCK Key="TBLX_ID_2」が送信されても（Ｓ46）、ユーザＡに関する仮ロック情報が既に削除されているため、独自ロックサーバ20からは本ロック設定不可の電文が送信され（Ｓ48）、データの更新が禁止される。

この場合、ユーザＡは「JKL」に更新された同データを再度呼び出し、必要であれば改めて本ロックの設定及びデータの更新を試行する。

上記のように本ロックが設定されている間は、テーブルＸの「ID=2」のデータについて第３者（例えばユーザＣ）のAPサーバが仮ロックの設定を申請しても、仮ロック情報（ユーザＣのID）の追記がなされることなく、待機させられる。そして、本ロック情報が削除された後、当該ユーザＣに関する仮ロック情報が新規に登録されることとなる。
また、本ロック設定中にユーザＡのAPサーバ14が本ロックの設定を申請しても、ユーザＡに係る仮ロック情報が存在しないため（本ロック情報に移行しているため）、本ロックの設定がなされることはない。

なお、上記のＳ32において本ロックの設定が完了した後に、何からの理由により一定時間内に本ロック解除の申請がAPサーバ18から返ってこない場合、独自ロックサーバ20はタイムアウトと認定し、当該本ロック情報を削除する。
この結果、ユーザＡに係る仮ロック情報も共に消滅するため、このタイミングでAPサーバ14から本ロックの設定申請が送信されても、本ロック設定不可の電文が返されることとなる。

このシステム10の場合、楽観ロック方式の実現に必要なロック情報が独自ロックサーバ20のメモリ上に設定され、DBサーバ22のテーブルＸにはバージョン情報を管理するデータ項目を設ける必要がないため、テーブル容量が徒に肥大化することを有効に抑えることができる。
また、APサーバ14(18)の検索処理部30及び更新処理部32もバージョン情報の更新処理から解放されるため、業務処理用アプリケーションプログラムの構成を簡素化することが可能となる。

もちろん、ロック処理部34を実現するためのプログラムをAPサーバ14(18)上に導入する必要が生じるが、独自ロックサーバ20との連絡処理に特化した共通のプログラム部品として予め用意しておき、業務処理用の各種アプリケーションプログラムがAPIを介してこれを随時呼び出すように仕組むことにより、コーディングの負担を大幅に軽減することができる。

上記においては２台のAPサーバ14(18)を備えたシステム10を例示したが、この発明はこのような構成に限定されるものではなく、１台のAPサーバを備えたシステムにも適用可能であり、また３台以上のAPサーバを備えたシステムにも同様に適用可能である。

この発明に係るデータベースのロック制御システムの全体構成を示す図である。 APサーバの機能構成を示すブロック図である。 このシステムにおける処理手順を示すフローチャートである。 従来の楽観ロック方式における処理手順を示すフローチャートである。

10 データベースのロック制御システム
12 ユーザＡのクライアント
14 ユーザＡのAPサーバ
16 ユーザＢのクライアント
18 ユーザＢのAPサーバ
20 独自ロックサーバ
22 DBサーバ
30 検索処理部
32 更新処理部
34 ロック処理部
Ａ ユーザ
Ｂ ユーザ
Ｘ テーブル

Claims (3)

1. ユーザの操作するクライアントと接続されたAPサーバと、当該APサーバと接続された独自ロックサーバ及びDBサーバを備えたシステムであって、
   上記APサーバは、データの検索処理に際しては、対象となるテーブル、レコード及びユーザの特定情報を伴う仮ロックの設定申請を上記独自ロックサーバに送信し、上記独自ロックサーバから仮ロック設定完了の通知があった場合には、上記DBサーバに対して該当レコードの抽出を依頼し、
   データの更新処理に際しては、対象となるテーブル、レコード及びユーザの特定情報を伴う本ロックの設定申請を上記独自ロックサーバに送信し、上記独自ロックサーバから本ロック設定完了の通知があった場合には、上記DBサーバに対して該当レコードの更新を依頼し、当該DBサーバから更新完了の通知が送信された場合には、上記独自ロックサーバに対して本ロックの解除申請を送信し、
   上記独自ロックサーバは、上記APサーバから仮ロックの設定申請が送信された場合に、対応のテーブル、レコードに関する仮ロック情報がメモリ上に存在しない場合には当該テーブル、レコード、ユーザの特定情報を伴う仮ロック情報をメモリ上に新規登録すると共に、当該APサーバに対して仮ロック設定完了の通知を送信し、
   仮ロック情報が存在する場合には当該ユーザの特定情報を既存の仮ロック情報に追加すると共に、当該APサーバに対して仮ロック設定完了の通知を送信し、
   また上記APサーバから本ロックの設定申請が送信された場合に、メモリ上に対応のテーブル、レコード、ユーザに関する仮ロック情報が存在する場合には当該仮ロック情報を本ロック情報に移行させると共に、本ロック設定完了の通知を上記APサーバに送信し、当該APサーバから本ロックの解除申請が送信された場合には対応の本ロック情報を削除することを特徴とするデータベースのロック制御システム。
2. 上記独自ロックサーバは、上記APサーバから仮ロックの設定申請が送信された場合に、上記仮ロック情報の他に、メモリ上に対応のテーブル、レコードに関する本ロック情報が存在するか否かをチェックし、
   本ロック情報が存在する場合には、当該本ロック情報が削除されるまで一時待機し、本ロック情報削除後に当該テーブル、レコード、ユーザの特定情報を伴う仮ロック情報をメモリ上に新規登録すると共に、当該APサーバに対して仮ロック設定完了の通知を送信することを特徴とする請求項１に記載したデータベースのロック制御システム。
3. ユーザの操作するクライアントと接続されたAPサーバと、当該APサーバと接続された独自ロックサーバ及びDBサーバを備えたシステムにおいて、
   データの検索処理に際しては、上記APサーバから上記独自ロックサーバに対し、対象となるテーブル、レコード及びユーザの特定情報を伴う仮ロックの設定申請が送信され、
   これを受けた独自ロックサーバは、メモリ上に対応のテーブル、レコードに関する仮ロック情報が存在しない場合には当該テーブル、レコード、ユーザの特定情報を伴う仮ロック情報をメモリ上に新規登録すると共に、当該APサーバに対して仮ロック設定完了の通知を送信し、
   仮ロック情報が存在する場合には当該ユーザの特定情報を既存の仮ロック情報に追加すると共に、当該APサーバに対して仮ロック設定完了の通知を送信し、
   これを受けた上記APサーバは、上記DBサーバに対して該当レコードの抽出を依頼し、
   データの更新処理に際しては、上記APサーバから上記独自ロックサーバに対し、対象となるテーブル、レコード及びユーザの特定情報を伴う本ロックの設定申請が送信され、
   これを受けた独自ロックサーバは、メモリ上に対応のテーブル、レコード、ユーザに関する仮ロック情報が存在する場合には当該仮ロック情報を本ロック情報に移行させると共に、本ロック設定完了の通知をAPサーバに送信し、
   これを受けた上記APサーバは、上記DBサーバに対して該当レコードの更新を依頼すると共に、当該DBサーバから更新完了の通知が送信された場合には、上記独自ロックサーバに対して本ロックの解除申請を送信し、
   これを受けた独自ロックサーバは、対応の本ロック情報を削除することを特徴とするデータベースのロック制御方法。

Images