メインコンテンツへスキップ

WEBマージでメモリーテーブルを使用

コメント

23件のコメント

  • nkmt

    webマージを使った事はないのですが、メモリーテーブルに式を指定した事はないです。
    私はクラサバとモバイルRIAでメモリーテーブルを使用しています。
    メモリーテーブルは式定義をして名前を変更などしなくても他社と被らないものと認識しておりました。

  • E_y

    nkmtさん、レスありがとうございます。

    メモリーテーブルについて

    ・クラサバは勿論、他のクライアントと被りません。同じクライアント内でもコンテキストを分ければ被らない事もできます。

    ・RIAもコンテキスト内での処理となりますので、他のコンテキストと被りません

    ・しかし、「コンテキスト無し」のWEBマージはサーバでの共通処理となりますので被ります。

     

    今回の案件は元々メモリーテーブルをそのまま使用しているシステムをマイグレする際に

    このままだとまずいだろうということで、苦肉の策で式を使うことで回避できないかと。

     

    メモリーに式を使っている事とエラーは全く別のもかも知れません。

    因みにエラーは毎回出るわけでなく、出たり出なかったりしています。何かヒントが得られないかと思い投稿した次第です。

    宜しくお願いします。

  • nkmt

    コンテキスト無しのWebマージではメモリテーブルは被るのですね。失礼しました。
    DBサーバーとWebアプリのサーバーは同一機なのですか?
    クラサバならLANが切れたようなメッセージかなーと思いました。

  • Pu

    こんにちはPuです
    webマージ多用しておりますがメモリーテーブルは特に意識せず使用しております
    今のところ問題は発生しておりません
    昔メモリーテーブルが初めてリリースされた時(pervasiveみたいな使い方が出来た)それぞれロックファイルが必要だったので端末番号毎に分けていた記憶がありますが
    最近はコンテキスト管理されていると伺ったので意識せず使用しております。
    webマージでも同様に意識してません。
    意識しないといけないのならかなり改修しないと...(XD)
    でわ~でわ~

  • E_y

    nkmtさん ありがとうございます。

    >DBサーバーとWebアプリのサーバーは同一機なのですか?

    別のサーバです。

    >クラサバならLANが切れたようなメッセージかなーと思いました。

    そうですね。メッセージだけを見るとデータベースへの接続関連ですね。

     

    データベースの設定等を確認しているところです。

  • nkmt

    電源設定 → 高パフォーマンスにすると、LANもお休みしないのですかね?

    LANアダプタのプロパティ
    → 省電力イーサネット(EEE)の設定を有効 改め 無効 も設定することがあったような気がします。

  • E_y

    Puさん ありがとうございます。

    >最近はコンテキスト管理されていると伺ったので意識せず使用しております。
    >webマージでも同様に意識してません。

    コンテキストを使用していれば問題ないです。コンテキストを使用していない場合はメモリーテーブルは共有するはずです(・・と思う)。

    実際に同じ処理を2つのブラウザから同時実行すると被りました。

    式を使用する事で別扱いで処理されています。

     

    私としてはpervasiveでは同じ様に式を使用した事があるのですが、メモリーでの実績がないため

    この方式に問題があるのか?・ないのか?が不明なため実績がある情報が得られれば安心できるかなと

    考えています。

  • E_y

    nkmtさん ありがとうございます。

    LANアダプタのプロパティも調査対象にします。

  • Pu

    こんにちはPuです
    WEBマージのPGはブローカーで起動されていると認識しております。
    同時に複数起動してもブローカーがコンテキスト管理しくれてるものと認識しております。
    でわ~でわ~

  • tanda

    E_yさん、

    アプリを再起動とかしたタイミングではないですか?

    コンテキストを指定していない場合は、メインプログラムのコンテキストが共有されるはずです。

    アプリを再起動したりすると、メインプログラムのコンテキストも再発行されますので。

  • E_y

    tandaさん ありがとうございます。

    コンテキストを指定していない場合は、メインプログラムのコンテキストが共有されるということはメモリーテーブルも共有されるとの認識です。

    コンテキストを指定している場合は、メインプログラムの変数やメモリーテーブルがコンテキスト単位で管理されるとの認識です。

    逆に私の認識が間違っていたほうが良いのですが・・・

  • E_y

    WEBマージでコンテキストを保持する設定はこの箇所です。

    今回はこの設定を使っていません。

  • tanda

    E_yさん、

    はい、コンテキストはそこで発行するのですが、マージはhtmlのフォーム送信ごとに、そこで発行されたコンテキストIDを指定してやる必要がありますね。

    コンテキストIDを指定せずにhtmlからフォームを送信すると、メインプログラムで管理しているそのコンテキストにたどり着けないという現象になってしまうでしょうね。

  • E_y

    tandaさん

    作成コンテキストの保持をする時は、htmlフォームのパラメータに"CTX"にてコンテキストIDを指定します。この機能は非常に便利で私の案件はできるかぎり使用しています。

    今回は昔ながらのコンテキスト「保持しない」の場合にメモリーテーブルをどの様に扱うのが正しいのでしょうか、ということろです。

  • tanda

    E_yさん、

    メモリーテーブルは基本的にコンテキストの保持が必須ですので、コンテキストを使用しない場合はいろいろな不具合が出そうですね。

    それらを環境またはタスクごとに個別に回避していくのは、大変な作業になるかと思います。まったく同じ環境やタスクが用意できれば検証も可能かもしれませんが。

    その点、RIAはコンテキストが自動管理されますので楽ですね。

  • k2

    お世話になります。

    Webマージでコンテキストを保持しない場合でもリクエスト毎にコンテキストは作成されるため、メモリテーブルは個別に管理されると思います。(リクエスト終了時にコンテキストが破棄される)
    よって、複数のマージリクエストが同じメモリテーブルを同時に利用しても混在することはない、という前提で利用しています。

    実際はどうなのでしょうか・・・

  • E_y

    k2さん ありがとうございます。

    Webマージでコンテキストを保持しない場合でも、一度作成したワークの内容は次のリクエストでも使用できていますので破棄はされていないと思われます。

  • k2

    E_yさん、

    違っていたらごめんなさい。
    開発版をフォアグラウンドで実行している場合は、そのような動作になるかも知れません。
    もし、開発版をフォアグラウンドで実行しているようでしたら、バックグラウンドで実行してみてください。

  • tanda

    k2さん、E_yさん、

    コンテキストがそのタスクまたはサブタスクで完結しているようなプログラム、例えばメモリテーブルのワーク内容を実テーブルに書き込んで終わり、というようなプログラムならそれでもいいのですが、たいていの場合はセッションが終了するまでそのメモリテーブルを参照するような作りになると思いますので、コンテキストIDは明示的に指定したほうがいいですよ。

    あと、バックグラウンドまたはマージサーバでの動作確認の必要性は、k2さんのおっしゃる通りだと思います。

  • E_y

    k2さん 皆様、ご協力ありがとうございます。

    サーバ実行版にてバックグラウンドにて動作確認をしています。

     

  • tanda

    E_yさん、

    ひょっとしてですが、サーバにMagic開発版とMagicサーバ実行版の両方をインストールされていませんか?
    その場合は、それぞれのリクエスタのパスを明示的に区分して指定する必要がありますが。

  • E_y

    tandaさん 皆様、ご協力ありがとうございます。

    開発版をインストールしていない本番環境での確認をしています。

  • E_y

    発生しているエラーについては少し進展があります。

    イベントビューワにMagicでエラーが発生している少し前の時間にTCPIPの警告が出ているため、このあたりを探って見ようと考えています。

サインインしてコメントを残してください。