遅延トランザクションの注意点について
RIAでないオンラインタスクで、
いままで伝票入力は、ワークファイルに書き込みを行い「更新しますか?」をおこなってきました。
今回ファイル数が多い為、ワークファイルを使わずに遅延トランザクションを考えております。
例)親タスク トランザクション D=遅延
子タスク ランザクション W=親と同一
RIA以外で遅延モードは、構築したことがありません。
注意点がありましたらご教授いただければとおもいます
-
umemoriさん、
ポイントは、「取消終了」イベントを用いた場合の動きと、Rollback()関数を用いたときの動きの違いですね。
レコードレベルのトランザクションと、タスクレベルのトランザクションとで動きが変わりますので、現場の要求に合わせて、好きなように設定できます。
「Magic連載コーナー」では詳細に解説していますので、よろしければお越しください。
-
いつもありがとうございます。参考にさせていただきます。
-
umemoriさん
tandaさん
こんにちは
すみません、
私はオンライン処理ならばトランザクションは物理と思っておりました。
実ファイルにも直接書き込んでおります。
何故遅延なのでしょうか?
大変申し訳ございません、ご教授ください。
-
tanadaさんの方が詳しいですが、簡単にいうと
物理トランザクション データ1行ごとにディスクに書き込みます。(この瞬間もとにもどすことができない)
遅延トランザクション データ1行ごとにディスクに書き込まず 確定時にコミットまたはロールバックが可能です。
RIAは、遅延です。遅延の場合、排他ロックがかからないと認識しています。
オンライン処理の場合 伝票入力でワークファイルに書込みを行い
「伝票作成しますか」で確定またはキャンセルをおこなっていましたが
遅延であればワークファイルがいらないとおもいます。
MSJでは、オンライン処理であっても遅延を推奨しているようです。
-
横から申し訳ありません。
遅延トランザクションにした場合に、最後のコミット時には遅延の中で処理された順に更新されるのでしょうか。
物理トランザクションの場合にはデッドロックにならないように更新順を気をつけてプログラムを組んでいます。
遅延トランザクションを使用されてる方は、デッドロック対策についてはどの様にされているのでしょうか。
宜しくお願い致します。
-
ご回答ありがとうございます。
物理は戻りますし、ロックをかけ、他のユーザが使用できないようにできます。
私の脳はコボルチックなので、オンラインでの遅延が難しいです。
そういえば、昔推奨していたような事を思い出しました。
-
sudoさん、
物理はDBが持つトランザクションで、遅延はMagic独自のトランザクションです。
物理はトランザクションのネストができませんが、遅延はネストが可能です。したがって、タスク単位でトランザクションが自由に設定できます。
なお、RIAの遅延はリアルタイムのロックができませんが、オンラインの遅延の場合はMagicロックを使用すればそれが可能です。 -
今データ管理を読んでおりました。
金額の更新は分かりました。
郵便番号の更新は使用できないような気がします。
MAGICロックとは何を指していますか?
(追記 郵便番号の同時更新)
-
sudoさん、
Magicロックとは、DBが持つロック機能を使わずに、Magicオリジナルのロック機能を使った排他制御です。
-
オンラインの遅延で即ロックできますか?
-
私は以下の通り理解しました。
マスタ関連は物理トラン
伝票の新規は遅延トラン
伝票の修正は物理トラン
いかがでしょうか?
-
sudoさん、
はい、オンラインの遅延も即時ロックができます。RIAは駄目です。
トランザクションの使い分けは、タスクの構造や開発者の好みに応じて、好きなように使い分けすればいいと思いますよ。
-
tandaさん
即時ロックはどこで設定しますか?
タスク特性の管理のロック方式には「入力時」しかありませんが…。
-
sudoさん、
Magicロックは、データベース特性の「オプション」で設定します。
ちなみに、「Magic連載コーナー」でも詳細に解説していますので、よろしければお越しください。
-
tandaさん
そこはレコード、テーブル、両方のみと思われます。
大変申し訳ございませんが、たぶんumemoriさんとE_yさんも分からないと思いますので、遅延で即時ロックを設定する方法を具体的に教えてください。
-
sudoさん、
はい、そこを「R=レコード」にし、動作環境で「mglock.dat」のパスを共有してやればロックが掛かりますよ。
この「mglock.dat」というファイルが、Magicが自前で排他制御を司るための共有ファイルとなります。
ちなみに、この方式は35年前の「dbMAGIC V4」の頃からのやり方と変わっていません。
-
sudoさん、
補足です。
この「mglock.dat」が共有できているかどうかは、それぞれのクライアントからMagicの実行版を起動して、その時に、このファイルが自動生成されるかどうかが確認できれば、認識されていることになります。
テストする場合は、テストのたびにmglock.datを明示的に削除してやると分かりやすいですよ。
-
昔、ビートリーブを使っていた時代にMagicロックでレコードロックしていました。
今はORACLEやMSSQLを使うようになってMagicロックは使っていないため、存在を忘れていました。
遅延トランザクションでも伝票のロックには使えそうですね。
-
E_yさん、
はい、昔は誰もがMagicロックを使っていたのですが、いつの頃からかDBが持つ排他制御が主流になってきて、忘れ去られたような存在になってしまいましたが、使い方によっては今でも重宝しますね。
-
tandaさん
何度も大変申し訳ございません。遅延ロックの意味は分かりました。
私は遅延で即時ロックを確認したかったのです。
即時とは、起動したらレコードをロックさせる方法です。
遅延で入力時や変更時にロックはできます。
そしてエラーイベントで相手に「項目が変更されましたよ」等のメッセージ発行はできます。
例えば、オンラインで同じ人の郵便番号を、2台同時に全く異なった値に変更する処理があった場合、遅延でやるにはどのようにするのが理想でしょうか?
私は物理で画面を先に出した人が優先にしておりました。
-
sudoさん、
「即ロック」というのは、そのことだったんですね。私はてっきり「リアルタイムロック」のことだと思っておりました。
確かに遅延にすると、「I=即時」のオプションは出てきませんね。「N=なし」か「O=入力時」になりますね。私は「O=入力時」で充分だと思っておりましたので、不自由を感じておりませんでした。「O=入力時」では何か問題がありますか?
ちなみに、Lock() 関数、Unlock() 関数を使われてみたことはありますか?
-
tandaさん
ありがとうございます。
そうなんです。即時ロックがしたかったのです。
ま、入力時でもいいのですが、
2つの例の場合となりますが、使用するユーザーにとっての気持ちの問題かと思います。
1.入力画面を表示し、「いざやるぞ」と思って、キーボードを入力したらロック
2.「いざやるぞ」と思って、入力画面が表示する前にロックまたは、照会画面
2番の方がやさしいような気がしまして。
Lock() 関数、Unlock() 関数は知りませんでした。リソースロックなのですね。
マスタメンテナンス等に使えそうですね。
で、郵便番号の場合はtandaさんならどのように制御しますか?
-
sudoさん、
二人の人が同時に郵便番号を変更しようとしたシーンなら、「O=入力時」でいいと思います。
それまでは二人ともデータが同じように見えているわけですから、このほうが便利だと思います。開発者の好みかもしれませんね。
sudoさんがお好きなように作ればいいと思いますよ。 -
sudoさん、
Lock() 関数を使用すればテーブルやレコードのロックのみならず、タスク自身や端末番号など、アプリケーションの中で使用されるあらゆるリソースにロックを掛けられますよ。
Magicに添付されたサンプルプログラムか、ヘルプに使い方の概要が載っていたはずです。sudoさんのお好みの動きやタイミングでロックを実現できると思いますよ。
ぜひ、参考資料を参照してみてください。
-
tandaさん
いろいろとありがとうございました。
遅延トランの仕組みを改めて理解することができました。
次に新システムを構築する時は遅延トランでいこうと思います。
Lock関数もその時に動作確認してみます。
umemoriさん
スレ大変申し訳ございませんでした。
とても勉強になりました。ありがとうございました。
-
大変勉強になりました。整合性などのチェックは、注意したいとおもいます。
-
sudoさん、
遅延トランザクションも、登場してからかれこれ18年近くになると思うのですが、やはりいくら良いものでも普及するのにそのくらいは掛かりますね。のんびり行こうと思っています。
サインインしてコメントを残してください。
コメント
27件のコメント