VB.netでのWebアプリケーションでsqlconnectionの接続、開放タイミング

Question

前提

VB.net/asp.netで構成されたWebアプリケーションの保守をやっています。
BtoB、BtoBtoC向けのシステムで、検索などを備えた会員システムと会員を管理する事業主用システムが主に存在しています。

上記システムでは全てのページにおいて、各ページクラス直下にSqlConnection変数を宣言しており、そのSqlConnectionに対してPage_Init内でOpenして、Page_PreRender内でDisposeしています。
また共通処理などの関数は、そのOpenされたSqlConnection型の変数を引数としてわたしており、使いまわしている状態です。

質問内容

・このような構成は一般的なものなのか。（一般的でなければ、どのような形が一般的か
・SQL実行毎にSqlConnectionをOpen、Closeする場合とパフォーマンス的な違いがあるか

といったことをご教授いただければと思います。

どうぞよろしくお願いいたします。

該当のソースコード

Public Class sample_aspx
    Inherits Page

    Dim con As SqlConnection
    Dim cmd As SqlCommand

    Protected Sub Page_Init(ByVal sender As Object, ByVal e As System.EventArgs)
        con = ConnectionStringのセット
        con.Open()
    End Sub
    Protected Sub Page_PreRender(ByVal sender As Object, ByVal e As System.EventArgs)
        con.Close()
        con.Dispose()
        cmd = Nothing
    End Sub

End Class

補足情報（FW/ツールのバージョンなど）

.NET Framework 4.8
サーバー情報
AWS EC2
アプリケーション用サーバー：Windows Server 2019 Datacenter/c5.9xlarge
DB用サーバー：Windows Server 2019 Datacenter/c5.9xlarge
Microsoft SQL Server 2017

Answer 1

このような構成は一般的なものなのか。（一般的でなければ、どのような形が一般的か

いいえ、どうしてもそうしなければならない特別な理由がない限り、

Page_Init内でOpenして、Page_PreRender内でDispose

とか、

また共通処理などの関数は、そのOpenされたSqlConnection型の変数を引数としてわたしており、使いまわしている状態です。

などと言うことはあり得ません。と言うより絶対やってはいけないことです。

(1) Open して使い終わったら即 Close する（コネクションプールの有効利用）、(2) 例外が発生しても確実に Close されるように using 句を使うとか try - finally の finally ブロックで確実に Close されるようにする（コネクションリークの防止）のが基本です。

SQL実行毎にSqlConnectionをOpen、Closeする場合とパフォーマンス的な違いがあるか

ASP.NET Web アプリなどでユーザーが普通に CRUD 操作を行うような場合は無いと思っていいはずです。実際それがボトルネックになっているのですか？　違いますよね。

Comments

[penta0205]

ご回答ありがとうございます。

＞絶対やってはいけないことです。
そうなのですね。
リソース的にもセキュリティ的にもCloseをSQL実行毎に行った方がよいということがなんとなくですが、わかりました。
たとえばですが、同じDBに対してPage_Loadで3回SELECT文を実行するとして、これは3回OPENCLOSEを行った方がよいのでしょうか？

＞ASP.NET Web アプリなどでユーザーが普通に CRUD 操作を行うような場合は無いと思っていいはずです。実際それがボトルネックになっているのですか？　違いますよね。
こちらは、すみませんがおっしゃておられる意味がよくわかりませんでした。
会員の検索画面などでは、直接会員テーブルに対してSELECTを行いますし、サービスを申し込むとテーブルに対してINSERTも行います。（おそらくそういう意味ではないのかと推測してますが。。）
実際問題、改良を続けてはいますが、10年以上続いているシステムです。
とくにどこがでボトルネックが発生しているとかそういったこともなく動作はしているかと思います。

[退会済みユーザー]

> たとえばですが、同じDBに対してPage_Loadで3回SELECT文を実行するとして、これは3回OPENCLOSEを行った方がよいのでしょうか？

その「例えば」が具体性がなくて分かりません。具体例を書いてください。

こちらも例えばですが、単一バッチで SELECT クエリを 3 つ実行するなら一つのコネクションで行うのが当たり前（というか、それしかできない）ですけど。

> こちらは、すみませんがおっしゃておられる意味がよくわかりませんでした。

普通でないことをしていた理由が、パフォーマンス上の問題（ボトルネック）を解決するための手段ではないですよね。だったら普通にやればいいでしょ・・・と言う意味です。

[penta0205]

説明不足で申し訳ないです。
Page_Loadの中で、1回目なにかしら値をSELECTしてその値を利用して次のSELECTをするときなど、、
つまり、一回でSELECTを複数回実行するのではなく、同じPage_Load内でプログラム処理をはさんで複数回実行する場合のことです。

＞普通でないことをしていた理由が、パフォーマンス上の問題（ボトルネック）を解決するための手段ではないですよね。だったら普通にやればいいでしょ・・・と言う意味です。
すみません、理解しました。
確かにおっしゃる通りかと思います。

[退会済みユーザー]

> 一回でSELECTを複数回実行するのではなく、同じPage_Load内でプログラム処理をはさんで複数回実行する場合のことです。

依然として具体性がないのでわかりません。

「プログラム処理」とは何ですか？　その処理間でなぜ接続を保持しなければならないのですか？　その理由を書けますか？

それなりの理由がなければ、using 句を使って、SELECT 処理が終わったら、即、確実にクローズされるようにすべきです。絶対に。

接続を使いまわした方が効率が良さそうだと単純に思い込んで、接続プールの有効利用とか、接続リークの防止とかは考えずにコーディングされているように見えますが、違いますか？

ちなみに、「それなりの理由」の例を挙げると、複数の SQL 文の実行をトランザクションに束ねるというようなことがあります。具体例は以下の記事を見てください。

SqlDataSource とトランザクション
http://surferonwww.info/BlogEngine/post/2010/11/16/SqlDataSource-and-manual-transaction-settings.aspx

上の記事では、SqlDataSource による SQL Server の UPDATE が成功したら、変更されたフィールド名、更新前／後の値、変更日時をログとして同じ SQL Server に INSERT する処置をトランザクションに束ねて行っています。

SqlDataSource.Updated イベントのハンドラで INSERT 処理を行っています。イベントハンドラの引数 SqlDataSourceCommandEventArgs から UPDATE に使った SqlConnection オブジェクトへの参照を取得できますので、それを INSERT 処理で使っています。

[penta0205]

Init PreRenderなどイベント毎にOpenCloseをしてしまうとCloseされない可能性があるという認識で、同じイベント中ならどうかとおもっただけでしたが、「確実にCloseをする必要がある」というところを念頭におくと処理が中断される可能性がある以上毎回OpenCloseを確かに行うべきだとわかりました。
またそうしない場合のこともご丁寧に回答くださりありがとうございます。参考にします。

sqlconnectionに対して認識が改まりました。
ありがとうございました。