C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[10]: 処理毎にコネクション確立する？

(過去ログ 170 を表示中)

[トピック内 23 記事 (1 - 20 表示)]　 << 0 | 1 >>

■98195 / inTopicNo.1)

　処理毎にコネクション確立する？

▼■

□投稿者/ furu (128回)-(2021/10/12(Tue) 10:48:43)

分類:[データベース全般]　

サーバー：Oracle 12c → Oracle Cloud 19c
クライアント：Windows10　SQL*Plus,C#など

DBサーバーをOracle Cloudに移行するにあたり
SQL*Plusでの作業やC#プログラムで困っています。

Oracle Cloudでは
セッションのアイドルタイムが5分以上になるとリソースを有効活用するため
セッションが切断されることがあるということがわかりました。
テストでは100%切断されました。
トランザクションが実行中でも切断されます。

https://docs.oracle.com/en/cloud/paas/autonomous-database/adbsa/idle-tile-limits.html#GUID-241F4C85-24E5-4F8A-B9EE-E3FCEF566D36

オラクルサポートへ何度か問い合わせし
サーバーからクライアントへの定期的な
異常監視（SQLNET.EXPIRE_TIMEパラメータ）することにより
切断を防止できることはわかりました。
しかし、本来の目的とは使用方法が違うし、
WEBでもこのような方法はあまり見つかりませんでした。

コネクションやプログラムでのトランザクションの使い方が
一般的な方法と違っているのかと悩んでいます。

１．C#プログラム（Windows Forms）で
　　起動時にコネクションをオープンし、
　　プログラム終了までコネクションは張りっぱなしにしています。
　　通常、処理毎にコネクションをオープンするものですか？
　　マスタ修正プログラムだと
　　　　表示するためselectでコネクション
　　　　更新するためupdateでコネクション
　　ですか？

２．C#プログラム（Windows Forms）で
　　トランザクションの最後に処理件数など表示し
　　メッセージボックスにてCommitしていいかの確認をしています。
　　この時、電話やトイレなどで5分以上「OK」ボタンを押せないと
　　セッションが切断され、Rollbackされてしまいます。
　　トランザクション中にオペーレーターの確認などしてはいけないものですか？

３．SQL*PlusなどでのSQL作業はCommitするまで
　　電話や調べものなど時間がかかるものはしないようにしていますか？

長文になり、申し訳ございません。
デフォルトでは5分で切断されるということに釈然としないものがありますが
自分のやり方に疑問は生じ、質問させていただきました。

引用返信 編集キー/

■98200 / inTopicNo.2)

　Re[1]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ WebSurfer (2361回)-(2021/10/12(Tue) 17:44:53)

■No98195 (furu さん) に返信

接続型データアクセスで Connection を Open してから Close するまで 5 分以上かかるケースが
あって、それが問題になるということですか？

自分的には 5 分とかは考えられない長さで、せいぜい 5 秒ぐらいが限度だと思っています。

なので、その程度になるよう手順・使用・設計などを考えるという話になるかと思っています。

Commit 可否の問い合わせが来るというのも自分的には考えられなくて、まして電話やトイレで OK
ボタンを押せないとことにまで対応しろと言う無茶な話もあり得ない話と思うのですが。

客の要求とかで何が何でもそうせざるを得ないという事情があるのでしょうか？　そうだとすると
ここで議論しても仕方のない話かも知れませんね。

引用返信 編集キー/

■98201 / inTopicNo.3)

　Re[2]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ furu (129回)-(2021/10/12(Tue) 19:28:39)

■No98200 (WebSurfer さん) に返信
回答ありがとうございます。

> 自分的には 5 分とかは考えられない長さで、せいぜい 5 秒ぐらいが限度だと思っています。
こういう話が聞きたかったことです。
手作業でデータ更新する場合も5秒ぐらいで行っているんですか？
その場でSQL叩くことはないのでしょうか？

2つのDBと接続して更新作業を行っている場合
片方のDBに対して、10分アクセスしてしていないことはよくあります。

> Commit 可否の問い合わせが来るというのも自分的には考えられなくて、まして電話やトイレで OK
> ボタンを押せないとことにまで対応しろと言う無茶な話もあり得ない話と思うのですが。
> 客の要求とかで何が何でもそうせざるを得ないという事情があるのでしょうか？
「対応しろ」ではなくて、そういうつくりにしていました。

コネクションをOpenのままにすると便利なことも多いです。
　・コネクション確立の時間が不要
　・リソース不足でコネクションが確立失敗することがない
　・マスタ更新などの排他制御にレコードロックが使える

> そうだとするとここで議論しても仕方のない話かも知れませんね。
別な意見もあるかもしれないので、そのままにさせていただきます。

引用返信 編集キー/

■98202 / inTopicNo.4)

　Re[3]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ WebSurfer (2362回)-(2021/10/12(Tue) 20:01:22)

■No98201 (furu さん) に返信

Open したままにしておくと便利だから Open したままにしておくという考え方では
なくて、5 秒で済むように考えるという方向に進むべきではないのですか？

引用返信 編集キー/

■98203 / inTopicNo.5)

　Re[3]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ くま (15回)-(2021/10/12(Tue) 20:15:55)

2021/10/12(Tue) 20:18:47 編集(投稿者)

別の意見が必要との事で
私の私見を書き込ませていただきます。

私もWebSurferさんのご意見と一緒で1処理は5～10秒程度と考えています。

>　・コネクション確立の時間が不要
>　・リソース不足でコネクションが確立失敗することがない
多人数の方が使われるなら使っていない状態が一定時間あるなら解放しないと
いつまでもリソースを使われたままなので解放してほしい。

>　・マスタ更新などの排他制御にレコードロックが使える
レコードロックの使い方が違うように感じます。
あくまで1処理を行う際、レコードを変更されないようにする仕組みがレコードロックで
画面上の更新あれば更新時間のチェック等で排他制御を行うべきかと思います。

>１．
> 表示するためselectでコネクション
> 更新するためupdateでコネクション
> ですか？
上記理由から、「はい」です。

>２．C#プログラム（Windows Forms）で
> メッセージボックスにてCommitしていいかの確認をしています。
内容の確認は更新前に行っておきます。よってUpdateが行われる前です。
Commitは1処理で複数SQLによる更新を同時に行うものと考えたほうが良いかと。

>３．SQL*PlusなどでのSQL作業はCommitするまで
>　電話や調べものなど時間がかかるものはしないようにしていますか？
Commitし忘れなどがあるかもしれませんから自分はすぐCommitします。
調べもの等で確認しないと分からない内容ならExcelでもすぐセーブします。

引用返信 編集キー/

■98204 / inTopicNo.6)

　Re[3]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ ニケ (25回)-(2021/10/13(Wed) 09:12:32)

2021/10/13(Wed) 09:17:58 編集(投稿者)

■No98201 (furu さん) に返信
コネクションプール、キャッシュ、シングルトンetc...共有の資産を使いまわすような
考え方は沢山あります。ただ、当然それぞれメリットデメリットがあります。また、
言語仕様などに依存して、実は実装テストしてみたら逆に遅くなったとか、PGの範囲で
なくDBの実装に任せた方が良かったりとか、一律の答えがあるとは思わない方が良いです。
ひとまず、それなりの意見を聞きたいなら上記にあげたようなキーワードは軽く勉強
して頂いて、その処理を採用した目的や理由とセットで質問して頂きたいです。

>１．C#プログラム（Windows Forms）で
>　　通常、処理毎にコネクションをオープンするものですか？
基本的には、はいです。
変数のスコープは、出来るだけ狭くした方がトラブルが少ないという観点からです。
正常に全てが上手くいっているなら便利かもしれませんが、エラーが起きた時の対処
では寧ろ不便に感じます。作法として自分の処理内で開始から後始末まで完結した方が
良いと考えます。他の処理が接続を開いている前提だから接続し直して。。。は他の
処理に依存するわけですから、面倒です。
また、DBから見れば5分も応答ない接続にはエラーで落ちた端末も含まれると思いますが、
帰ってこないご主人様を待つ忠犬を数千、数万…と飼い続けるのが効率的でしょうか？
無操作5分は切断するに十分な時間だと思います。

>２．C#プログラム（Windows Forms）で
>　　トランザクション中にオペーレーターの確認などしてはいけないものですか？
まず、データの更新が発生する場合、確認する方がより良いシステムです。
しかし、それをトランザクション中に行うのは疑問に思います。
入力による整合性は、オペレーターによる全ての入力が終わった時点で1回だけ行うのが
基本だと考えます。その後にトランザクションを開始し、処理を出来るだけ短くすべきだと
思います。
万が一、複数のトランザクションを順番に実行、かつ結果を途中で確認する必要があった場合、
私はタイムアウトを積極的に取り入れると思います。オペレーターへの確認時にカウントダウンも
表示し「5分以内に処理を完了させない場合、一旦キャンセルされます」とか表示するかもしれません。

>３．SQL*PlusなどでのSQL作業はCommitするまで
>　　電話や調べものなど時間がかかるものはしないようにしていますか？
SQLの編集中に接続しっぱなしがナンセンスで、それはつまり、同じ口座に入金する銀行
システムで、1つの振込処理が開始されると他からの入金は5分以上待たされるという事ですか？
共通の資産を使う以上、一人が占有する時間を短くするのは基本中の基本に考えます。

>　・コネクション確立の時間が不要
今どき、実測値は問題にならないことの方が多いのでは。
>　・リソース不足でコネクションが確立失敗することがない
一人が占有し続けるために発生するリソース不足もあります。
>　・マスタ更新などの排他制御にレコードロックが使える
(※かつ↑の状態を5分以上保持しないといけない)
月度更新など、システム全体を止めて長時間処理するならあり得るが、日常業務で必要に
なる可能性は低いでしょう。むしろイレギュラーな処理でしか使わないように思います。

引用返信 編集キー/

■98205 / inTopicNo.7)

　Re[3]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ WebSurfer (2363回)-(2021/10/13(Wed) 09:43:37)

■No98201 (furu さん) に返信

非接続型データアクセスをご存じないということはないですよね？

もしご存じないということでしたら、ADO.NET での典型的な例が以下の記事にあります
ので、図１と図２を見るだけでもいいので、見てください。

非接続型のデータ更新
https://docs.microsoft.com/ja-jp/previous-versions/cc482903(v=msdn.10)?redirectedfrom=MSDN#%E9%9D%9E%E6%8E%A5%E7%B6%9A%E5%9E%8B%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E6%9B%B4%E6%96%B0

> 手作業でデータ更新する場合も5秒ぐらいで行っているんですか？

上のような方法ならば Open から Close までは 5 秒もかかりません。

> 2つのDBと接続して更新作業を行っている場合
> 片方のDBに対して、10分アクセスしてしていないことはよくあります。

クライアントの PC のメモリ上にある DataSet / DataDable を編集するので 10 分でも、
20 分でも、電話に出たりトイレに行ったりでそれよりもっと長くなったりしても問題あり
ません。

引用返信 編集キー/

■98206 / inTopicNo.8)

　Re[4]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ furu (130回)-(2021/10/13(Wed) 14:21:46)

みなさん、回答ありがとうございます。
別途、返信させていただきます。

コネクションの接続タイミングに関するものを見つけました。
（コピーライトは2009年）

https://www.oracle.com/jp/technical-resources/articles/secret-of-oracle-site.html#p01c

　いつコネクションを生成すれば良いのか？
　　1.SQLを1つ発行するごと
　　2.トランザクションを1つ開始するごと
　　3.ログインなど、大きな処理単位ごと
　　　この考え方は現在でも主流の1つです。
　　　「ログインからログアウトまで」「処理単位開始から終了まで」といった複数のトランザクションを
　　　含む大きな処理単位で1つのコネクションを保持します。
　　　…使用ユーザーが少数に特定されている場合や一度ログインすると
　　　1日中接続を保持したままのアプリケーションなどはこの形式を好みます。
　　4.半永久的に接続したまま

私がやっているのは、3.になります。
12年前ぐらいに「この考え方は現在でも主流の1つ」と書かれているので
今でもこうしているシステムは少なからずあるのではないでしょうか？

引用返信 編集キー/

■98207 / inTopicNo.9)

　Re[5]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ くま (16回)-(2021/10/13(Wed) 15:23:24)

furuさんが提示されたURL拝見しまいた。
oracleが発行している資料だけによくできている内容だと思います

ただ基本条件として
a.クライアントPC(C#)→社内ネットワーク→サーバ上DB(oracle)
b.クライアントPC(C#)→インターネット→クラウドサーバ上DB(oracle)
では考え方が違うという点です。

クラウドサービスでは1契約で1サーバではありません。
よってリソースを消費したままでは他の契約に影響を与える可能性がありますので
同時接続数や接続時間に制限を設けているのが一般的です。

あとサーバ上で実行されるソフト(C#)とクライアントPC(C#)でも考え方は変わってきます。

この辺りはfuruさんが提示されたURLの
「アイドル論理接続の奪取と切断」が参考になるかと

引用返信 編集キー/

■98208 / inTopicNo.10)

　Re[4]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ furu (131回)-(2021/10/13(Wed) 18:38:20)

■No98202 (WebSurfer さん) に返信
> ■No98201 (furu さん) に返信
> Open したままにしておくと便利だから Open したままにしておくという考え方では
> なくて、5 秒で済むように考えるという方向に進むべきではないのですか？
今後はそういうことも考えなくてはいけないですね。

引用返信 編集キー/

■98209 / inTopicNo.11)

　Re[4]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ furu (132回)-(2021/10/13(Wed) 20:07:01)

■No98204 (ニケさん) に返信
丁寧な回答ありがとうございます。

> ■No98201 (furu さん) に返信
> また、言語仕様などに依存して、実は実装テストしてみたら逆に遅くなったとか、PGの範囲で
> なくDBの実装に任せた方が良かったりとか、一律の答えがあるとは思わない方が良いです。
真逆の意見をいろいろ聞けて
今回質問してみてよかったです。

> また、DBから見れば5分も応答ない接続にはエラーで落ちた端末も含まれると思いますが、
> 帰ってこないご主人様を待つ忠犬を数千、数万…と飼い続けるのが効率的でしょうか？
> 無操作5分は切断するに十分な時間だと思います。
効率的かどうかはともかく
ネットワーク層(TCP/IP)で通信エラーでないのに
DBサーバーから切断されたのが初めてなので驚いています。

それに5分ぐらいで切断するなら
Keep aliveのデフォルトが2時間とはおかしなことです。

Oracle Cloudという安価なクラウド環境を提供するため
新たに設けられたと思っています。

> システムで、1つの振込処理が開始されると他からの入金は5分以上待たされるという事ですか？
5分以上待たせてもいい処理だったということです。

> >　・コネクション確立の時間が不要
> 今どき、実測値は問題にならないことの方が多いのでは。
この件に関しては申し訳ない。
なんでコネクション確立が遅くなるのか考えてみたら
現行のシステムがセキュリティ上
プログラム内やPC内にパスワード持ってなくて
コネクションのOpen前に必ず別サーバーに聞きに行く
処理が走っているからでした。

でもコネクション確立は時間かかりますよね。
それでなかっらコネクションプールなんて必要ないと思います。

> >　・リソース不足でコネクションが確立失敗することがない
> 一人が占有し続けるために発生するリソース不足もあります。
現行のシステムでは想定外でした。

引用返信 編集キー/

■98211 / inTopicNo.12)

　Re[6]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ furu (133回)-(2021/10/13(Wed) 20:17:40)

■No98207 (くまさん) に返信
> ただ基本条件として
> a.クライアントPC(C#)→社内ネットワーク→サーバ上DB(oracle)
> b.クライアントPC(C#)→インターネット→クラウドサーバ上DB(oracle)
> では考え方が違うという点です。
>
> クラウドサービスでは1契約で1サーバではありません。
> よってリソースを消費したままでは他の契約に影響を与える可能性がありますので
> 同時接続数や接続時間に制限を設けているのが一般的です。
そうなんですよね。クラウドだからなんですよね。

オンプレミスからクラウドへの移行のメリット／デメリットを
かなり調べてたり、聞いたりしたのですが
アイドルタイムが5分以上で切断されかもしれない（テストでは100％）という
話はどこにも出てきてませんでした。
困っていればネットに愚痴が書かれる筈です。
それで本当にみんな困らないのかと今回質問させていただきました。

引用返信 編集キー/

■98212 / inTopicNo.13)

　Re[4]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ furu (134回)-(2021/10/13(Wed) 20:48:59)

■No98205 (WebSurfer さん) に返信
> ■No98201 (furu さん) に返信
>
> 非接続型データアクセスをご存じないということはないですよね？
非接続型データアクセスって言うんですね。
DataSetは昔試してみたのですが
以下のような理由で使わなかったです。

　・not null制約が付いた列に対して、nullを書き込めない。
　　小さな親切ですね。
　　値はトリガーで設定してます。
　・SQLの変更に対して、コメントが書けない。
　・SQLの方言が書けない。
　・列名，テーブル名に定数・変数が使えない。
　・更新で条件にすべての列（それもnullを考慮した）が列挙され無駄。
　　排他制御していれば、プライマリーキーだけで十分。
　・「元のデータと同じなら更新していいだろう」を信じていない。

当時、こう思っていたので、間違いがあれば指摘願います。

引用返信 編集キー/

■98213 / inTopicNo.14)

　Re[5]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ 魔界の仮面弁士 (3190回)-(2021/10/13(Wed) 22:00:54)

2021/10/13(Wed) 22:06:46 編集(投稿者)

■No98212 (furu さん) に返信
> 非接続型データアクセスって言うんですね。
ADO.NET 登場前の ADO でも、接続型と非接続型を利用できましたね。
(切断型 Recordset の永続化機構や、UpdateBatch メソッドなど)

> DataSetは昔試してみたのですが
> 以下のような理由で使わなかったです。
DataSet について少し補足。

> 　・not null制約が付いた列に対して、nullを書き込めない。
> 　　小さな親切ですね。
書き込むこともできますよ。

DataSet の EnforceConstraints プロパティを false にすると、
制約違反のデータを書き込めます。(null不可、桁数溢れ、リレーション違反など)

制約違反のデータがある場合、EnforceConstraints を true に戻した段階で
例外が発生するので、それを捕らえた上で
　DataSet.HasErrors プロパティ
　DataTable.HasErrors プロパティ
　DataRow.HasErrors プロパティ
　DataTable.GetErrors メソッド
　DataRow.GetColumnsInError メソッド
　DataRow.GetColumnError メソッド
などを用いて、エラーの発生した表/行/列を特定できます。

DataGridView などでは、エラー状態になったセルにエラーアイコンを表示する機能もあったので、
データを再補正するなり取り消すなりして、再度、制約チェックをやり直すという流れです。

> 　・SQLの変更に対して、コメントが書けない。
> 　・SQLの方言が書けない。
それは DataSet に関するものではなく、ADO.NET データプロバイダー側の話ではないでしょうか。
使用可能な SQL 構文は、データプロバイダーによって異なりますね。

> 　・列名，テーブル名に定数・変数が使えない。
DataSet の列名やテーブル名には、変数を使えますよ。
DataColumn 型の変数でも良いですし、列番号や列名でもアクセスできます。

あるいはもしかして、型付 DataSet の TableAdapter の話をされているのでしょうか?

列名や表名を、SQL のパラメーターとすることをサポートしていないデータベースは多いですね。
データソースが確定していないと「オプティマイザが使えなくなるから」というのがその理由ですが、
そうした場合でも、動的 SQL を使うことはできますね。
動的 SQL を DataAdapter に渡して DataSet に入れる事も出来ますし、
Dapper.NET を使うという選択肢もあります。

> 　・更新で条件にすべての列（それもnullを考慮した）が列挙され無駄。
> 　　排他制御していれば、プライマリーキーだけで十分。
> 　・「元のデータと同じなら更新していいだろう」を信じていない。
これも DataSet とは関係ない話のような…。
DataAdapter や TableAdapter の話と混同されている気がしますが、
ROWID や主キーのみを使った排他制御機構は可能ですよ。

すべての列をチェックするかどうかは、開発者が決めることで、
たとえば TableAdapter のウィザードを使った場合でも、
こういった選択肢が提示されていました。
https://docs.microsoft.com/ja-jp/aspnet/web-forms/overview/data-access/editing-inserting-and-deleting-data/implementing-optimistic-concurrency-cs

引用返信 編集キー/

■98214 / inTopicNo.15)

　Re[5]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ WebSurfer (2364回)-(2021/10/13(Wed) 22:32:45)

■No98212 (furu さん) に返信

どうしても自分の道を進みたいって感じがします。
なので、一番最初のレスで言いましたけど、議論しても仕方のない話ですね。

引用返信 編集キー/

■98215 / inTopicNo.16)

　Re[6]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ くま (18回)-(2021/10/14(Thu) 04:54:42)

> アイドルタイムが5分以上で切断されかもしれない（テストでは100％）という
> 話はどこにも出てきてませんでした。
> 困っていればネットに愚痴が書かれる筈です。

私も、すべてのプロジェクトを知っているわけではないのでのですが

1. 1990年頃までは1処理毎にコネクションを接続していた。
これはサーバやDBソフトの性能の関係でリソースをあまり持てなかった為

2. 2000年頃はサーバの性能も上がり社内の一部だけが利用するという事もあり
DBコネクションはクライアントソフト起動時1回という構成で作成していました。
性能が上がったといってもまだまだ接続やSQLの実行速度は遅かったですから。

3. 2010年前後の頃は皆がDBへアクセスできサーバの性能もさらに向上
クライアントPCの性能も上がり、そうすると利用者の増加とセキュリティの問題が発生
よってDBコネクションの常時接続は不適切となり処理毎となる。
この頃になるとSQL実行速度等も問題ない速さでした。

4. 2010年頃クラウド上DBが徐々に発表される(SaaS、PaaS、IaaS)
前期3.で対応した為「アイドルタイムが5分以上」で処理で困る事はありませんでした。
あとこの頃から「ブラウザ画面によるシステム(SaaS)」がほとんどでしたから
DB要求に対する応答が1画面処理で完結しないので自然に処理毎にコネクションとなっていました。

またコネクションに関しては共通関数化している事が普通で、影響もほとんどありませんでしたね。

現状クラウドDBで「アイドルタイムが5分以上で切断される」のには理由があります
お話を聞いている限り、レコードロックやコミット等ちょっと違う使われ方をされているご様子
これ以上の処理破綻となる前に修正される事をオススメします。

もしすでに作られていて、修正箇所が多い等どうしてもというのであれば
「画面を開いてアイドルタイムが5分経過したら、メッセージを表示して再取得してもらう」
とかでしょうか？

※MAX_IDLE_TIMEで48時間までは延長できそうですけども
別サーバでの常時応答APIでも無いかぎり延長はしないほうが良いかと思います。

引用返信 編集キー/

■98216 / inTopicNo.17)

　Re[6]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ furu (135回)-(2021/10/14(Thu) 09:31:05)

■No98213 (魔界の仮面弁士さん) に返信
> DataSet について少し補足。
魔界の仮面弁士さん
お手を煩わせてしまい、申し訳ございません。

DataSetだけでなく、DataAdapterなどもテストしたしてたんですね。
記憶があいまいです。

コメントが書けないことやWhereに条件多く困ったのは
他の人のプログラム修正だったような気がします。

> すべての列をチェックするかどうかは、開発者が決めることで、
> たとえば TableAdapter のウィザードを使った場合でも、
> こういった選択肢が提示されていました。
> https://docs.microsoft.com/ja-jp/aspnet/web-forms/overview/data-access/editing-inserting-and-deleting-data/implementing-optimistic-concurrency-cs
これは時間がある時、読んでみます。

引用返信 編集キー/

■98217 / inTopicNo.18)

　Re[6]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ furu (136回)-(2021/10/14(Thu) 09:39:08)

■No98214 (WebSurfer さん) に返信
> ■No98212 (furu さん) に返信
>
> どうしても自分の道を進みたいって感じがします。
はい、基本的にはそうです。

引用返信 編集キー/

■98218 / inTopicNo.19)

　Re[7]: 処理毎にコネクション確立する？

▲▼■

□投稿者/ furu (137回)-(2021/10/14(Thu) 10:54:11)

■No98215 (くまさん) に返信
くまさん、わかりやすく勉強になります。

> 2. 2000年頃はサーバの性能も上がり社内の一部だけが利用するという事もあり
> DBコネクションはクライアントソフト起動時1回という構成で作成していました。
> 性能が上がったといってもまだまだ接続やSQLの実行速度は遅かったですから。
私はこの時のやり方で止まっているようです。

データベース(RDB)を本格的に使用したのは
1995年頃のNetware+Oracle6でDelphiでアクセスしてました。
この頃書いたプログラムが現役で動いていますが
そのやり方のまま、20年以上経ってしまいました。
困りませんでしたので。

> 4. 2010年頃クラウド上DBが徐々に発表される(SaaS、PaaS、IaaS)
> 前期3.で対応した為「アイドルタイムが5分以上」で処理で困る事はありませんでした。
> あとこの頃から「ブラウザ画面によるシステム(SaaS)」がほとんどでしたから
> DB要求に対する応答が1画面処理で完結しないので自然に処理毎にコネクションとなっていました。
WEBシステムだと逆にトランザクション開始したまま画面遷移は難しいでしょうね。
「戻る」ボタン押されたり、URLで直接遷移されたりするし。

> 現状クラウドDBで「アイドルタイムが5分以上で切断される」のには理由があります
> お話を聞いている限り、レコードロックやコミット等ちょっと違う使われ方をされているご様子
> これ以上の処理破綻となる前に修正される事をオススメします。
ありがとうございます。
修正検討します。

> ※MAX_IDLE_TIMEで48時間までは延長できそうですけども
> 別サーバでの常時応答APIでも無いかぎり延長はしないほうが良いかと思います。
以前からMAX_IDLE_TIMEは設定しています。
MAX_IDLE_TIMEは指定された時間までアイドルだったら切断するというもので
指定された時間まで待ってくれるというものではありませんでした。

MAX_IDLE_TIMEの設定にかかわらず、Oracle Cloudでは5分以上アイドルだったら
切断されるかも（テストでは100％）しれないということです。

それと信じられないのですが
SQLNET.EXPIRE_TIMEを4分に設定し、サーバーからクライアントの監視をすると
5分以上のアイドルでも切断されなくなります。（最初の質問に記載）

サーバーのリソースは無駄にはなりますが
サポートからの回答でもあり
とりあえずはSQLNET.EXPIRE_TIMEパラメータを設定し、乗り切ります。

長くなりましたので、そろそろ店終いにします。

解決済み

引用返信 編集キー/

■98219 / inTopicNo.20)

　Re[7]: 処理毎にコネクション確立する？

▲　■

□投稿者/ WebSurfer (2365回)-(2021/10/14(Thu) 13:26:52)

■No98217 (furu さん) に返信
> ■No98214 (WebSurfer さん) に返信
>>■No98212 (furu さん) に返信
>>
>>どうしても自分の道を進みたいって感じがします。
> はい、基本的にはそうです。

ならば最初からそう書いておいてください。

余計な時間と手間をかけさせられた感じです。

引用返信 編集キー/

次の20件＞
トピック内ページ移動 / << 0 | 1 >>

- Child Tree -