WEBマージでメモリーテーブルを使用
お世話になります。
バージョンはxpa4.6です。
私が着手している案件ではないのですが、WEBマージでワークファイルにメモリーテーブルを使用している案件があります。コンテキストは使っていません。
他のユーザとメモリーテーブルを同時使用しないように、ログインユーザ毎にメモリーテーブルに式を指定しています。
処理開始時にdbdelをしてから、SqlServerのデータを(SQLは使っていません)複数階層のバッチでワークを作成して表示しています。
このような使い方には問題があるのでしょうか。
これが理由ではないのかも知れせんが、時間のかかる処理でエラーが出ます。
新規登録できません：（テーブル名1）：（テーブル名2）：
Named Pipes Provider:Could not open connection to SQL Server [5].
※（テーブル名1）：（テーブル名2）はそのタスクでリンクしている２つのテーブルです。
毎回エラーになるわけではなく、たまにエラーになります。
各タイムアウトの設定はデフォルトのままです。
このような現象にあわれた方はいないでしょうか。
-
webマージを使った事はないのですが、メモリーテーブルに式を指定した事はないです。
私はクラサバとモバイルRIAでメモリーテーブルを使用しています。
メモリーテーブルは式定義をして名前を変更などしなくても他社と被らないものと認識しておりました。 -
nkmtさん、レスありがとうございます。
メモリーテーブルについて
・クラサバは勿論、他のクライアントと被りません。同じクライアント内でもコンテキストを分ければ被らない事もできます。
・ＲＩＡもコンテキスト内での処理となりますので、他のコンテキストと被りません
・しかし、「コンテキスト無し」のＷＥＢマージはサーバでの共通処理となりますので被ります。
今回の案件は元々メモリーテーブルをそのまま使用しているシステムをマイグレする際に
このままだとまずいだろうということで、苦肉の策で式を使うことで回避できないかと。
メモリーに式を使っている事とエラーは全く別のもかも知れません。
因みにエラーは毎回出るわけでなく、出たり出なかったりしています。何かヒントが得られないかと思い投稿した次第です。
宜しくお願いします。
-
コンテキスト無しのWebマージではメモリテーブルは被るのですね。失礼しました。
DBサーバーとWebアプリのサーバーは同一機なのですか？
クラサバならLANが切れたようなメッセージかなーと思いました。 -
こんにちはPuです
webマージ多用しておりますがメモリーテーブルは特に意識せず使用しております
今のところ問題は発生しておりません
昔メモリーテーブルが初めてリリースされた時（pervasiveみたいな使い方が出来た）それぞれロックファイルが必要だったので端末番号毎に分けていた記憶がありますが
最近はコンテキスト管理されていると伺ったので意識せず使用しております。
webマージでも同様に意識してません。
意識しないといけないのならかなり改修しないと．．．(XD)
でわ～でわ～ -
nkmtさん ありがとうございます。
>DBサーバーとWebアプリのサーバーは同一機なのですか？
別のサーバです。
>クラサバならLANが切れたようなメッセージかなーと思いました。
そうですね。メッセージだけを見るとデータベースへの接続関連ですね。
データベースの設定等を確認しているところです。
-
電源設定 → 高パフォーマンスにすると、LANもお休みしないのですかね？
LANアダプタのプロパティ
→ 省電力イーサネット(EEE)の設定を有効 改め 無効 も設定することがあったような気がします。 -
Puさん ありがとうございます。
>最近はコンテキスト管理されていると伺ったので意識せず使用しております。
>webマージでも同様に意識してません。コンテキストを使用していれば問題ないです。コンテキストを使用していない場合はメモリーテーブルは共有するはずです（・・と思う）。
実際に同じ処理を２つのブラウザから同時実行すると被りました。
式を使用する事で別扱いで処理されています。
私としてはpervasiveでは同じ様に式を使用した事があるのですが、メモリーでの実績がないため
この方式に問題があるのか？・ないのか？が不明なため実績がある情報が得られれば安心できるかなと
考えています。
-
nkmtさん ありがとうございます。
LANアダプタのプロパティも調査対象にします。
-
こんにちはPuです
WEBマージのPGはブローカーで起動されていると認識しております。
同時に複数起動してもブローカーがコンテキスト管理しくれてるものと認識しております。
でわ～でわ～ -
E_yさん、
アプリを再起動とかしたタイミングではないですか？
コンテキストを指定していない場合は、メインプログラムのコンテキストが共有されるはずです。
アプリを再起動したりすると、メインプログラムのコンテキストも再発行されますので。
-
tandaさん ありがとうございます。
コンテキストを指定していない場合は、メインプログラムのコンテキストが共有されるということはメモリーテーブルも共有されるとの認識です。
コンテキストを指定している場合は、メインプログラムの変数やメモリーテーブルがコンテキスト単位で管理されるとの認識です。
逆に私の認識が間違っていたほうが良いのですが・・・
-
WEBマージでコンテキストを保持する設定はこの箇所です。
今回はこの設定を使っていません。
-
E_yさん、
はい、コンテキストはそこで発行するのですが、マージはhtmlのフォーム送信ごとに、そこで発行されたコンテキストIDを指定してやる必要がありますね。
コンテキストIDを指定せずにhtmlからフォームを送信すると、メインプログラムで管理しているそのコンテキストにたどり着けないという現象になってしまうでしょうね。
-
tandaさん
作成コンテキストの保持をする時は、htmlフォームのパラメータに"CTX"にてコンテキストIDを指定します。この機能は非常に便利で私の案件はできるかぎり使用しています。
今回は昔ながらのコンテキスト「保持しない」の場合にメモリーテーブルをどの様に扱うのが正しいのでしょうか、ということろです。
-
E_yさん、
メモリーテーブルは基本的にコンテキストの保持が必須ですので、コンテキストを使用しない場合はいろいろな不具合が出そうですね。
それらを環境またはタスクごとに個別に回避していくのは、大変な作業になるかと思います。まったく同じ環境やタスクが用意できれば検証も可能かもしれませんが。
その点、RIAはコンテキストが自動管理されますので楽ですね。
-
お世話になります。
Webマージでコンテキストを保持しない場合でもリクエスト毎にコンテキストは作成されるため、メモリテーブルは個別に管理されると思います。（リクエスト終了時にコンテキストが破棄される）
よって、複数のマージリクエストが同じメモリテーブルを同時に利用しても混在することはない、という前提で利用しています。実際はどうなのでしょうか・・・
-
k2さん ありがとうございます。
Webマージでコンテキストを保持しない場合でも、一度作成したワークの内容は次のリクエストでも使用できていますので破棄はされていないと思われます。
-
E_yさん、
違っていたらごめんなさい。
開発版をフォアグラウンドで実行している場合は、そのような動作になるかも知れません。
もし、開発版をフォアグラウンドで実行しているようでしたら、バックグラウンドで実行してみてください。 -
k2さん、E_yさん、
コンテキストがそのタスクまたはサブタスクで完結しているようなプログラム、例えばメモリテーブルのワーク内容を実テーブルに書き込んで終わり、というようなプログラムならそれでもいいのですが、たいていの場合はセッションが終了するまでそのメモリテーブルを参照するような作りになると思いますので、コンテキストIDは明示的に指定したほうがいいですよ。
あと、バックグラウンドまたはマージサーバでの動作確認の必要性は、k2さんのおっしゃる通りだと思います。
-
k2さん 皆様、ご協力ありがとうございます。
サーバ実行版にてバックグラウンドにて動作確認をしています。
-
E_yさん、
ひょっとしてですが、サーバにMagic開発版とMagicサーバ実行版の両方をインストールされていませんか？
その場合は、それぞれのリクエスタのパスを明示的に区分して指定する必要がありますが。 -
tandaさん 皆様、ご協力ありがとうございます。
開発版をインストールしていない本番環境での確認をしています。
-
発生しているエラーについては少し進展があります。
イベントビューワにMagicでエラーが発生している少し前の時間にTCPIPの警告が出ているため、このあたりを探って見ようと考えています。
サインインしてコメントを残してください。
コメント
23件のコメント