« Oracleの接続方法 | トップページ | DBMS_OUTPUTパッケージ »

2007年1月 3日 (水)

DBXInspectorの排他制御

今回はDBXInspector内部で行っている排他制御に関しての話です。といっても、排他制御と言えるほどおおげさなものでもありません。まずは、更新の消失つまりロストアップデートについてです。わかりやすく、下の図のように、SELECT文を発行し、グリッド上でデータを変更するシナリオを考えてみます。

Image1_3 

ここで、選択されているA列が7の行のB列を10に更新しようとして、B列を変更し確定するために、選択行を移動させます。この時、SELECT文を発行してから、編集するまでの間に、他のユーザーによって該当行が変更されている可能性があります。それを知らずに、更新してしまうと大抵は問題なので、つまり、ロストアップデートを防ぐために、選択されたすべての列が変更されていないかチェックします。このようにロストアップデートを防ぎます。よって、

グリッド上で更新する場合、なるべく、多くの列を含めてSELECTして下さい。特に更新された日付を表す列をもっている場合はそれを含めてください。

また、DBXInspectorはデータの変更に注意を払うというスタンスの元で開発されているので、グリッド上でデータを変更し、他の行に移動し確定してもUpdate文は発行されますが、デフォルトでコミットは自動では行われません。よって、トランザクションをコミットする場合は、コミットボタンを押すか、エディタ上でCOMMIT文を入力し、実行ボタンを押してください。言い換えると、

グリッド上でデータを変更したまま、トランザクションをコミットまたはロールバックせずにいると該当行がロックされたままになり、他のユーザーは更新する事はできません

つまり、楽観的ロック(Optimistic Lock)を行います。楽観的ロックとは、更新したい対象の行を照会してもロックはかけず、本当に更新が必要になった段階でその対象行にロックをかけることです。それに対して、悲観的ロック(Perssimistic Lock)とは、更新したい対象行を照会する時点でロックをかけることです。悲観的ロックを用いて、グリッド上などで変更したい場合は、SELECT文にFOR UPDATE句を含めて下さい。

なんか、色々文字を太字にしたり、色変えてるが見にくぃ。

« Oracleの接続方法 | トップページ | DBMS_OUTPUTパッケージ »

DBXInspector」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/1497665/39651912

この記事へのトラックバック一覧です: DBXInspectorの排他制御:

« Oracleの接続方法 | トップページ | DBMS_OUTPUTパッケージ »

自作ソフトウェア

無料ブログはココログ

メモ