問題タブ [apache-dbi]

子プロセスで Apache::DBI を使用すると問題が発生します。問題は、Apache::DBI がそれを使用するすべてのプロセスに対して単一のハンドルを提供することです。

DBD::mysql::db selectall_arrayref が失敗しました: コマンドが同期していません。/usr/local/www/apache22/data/test-fork.cgi 20 行目でこのコマンドを実行することはできません。

次のエラーを理解したので、Apache::DBI はすべてのプロセスで再接続するため、再接続は役に立ちません。

サーバーで内部エラーが発生し、リクエストを完了できませんでした。

エラー メッセージ: DBD ドライバーは、/usr/local/lib/perl5/site_perl/5.8.9/Apache/DBI.pm 行 283 で AutoCommit 属性を実装していません。

元のコードは次のとおりです。

再接続に使用したコード:

fork で Apache::DBI を安全に使用する方法はありますか? おそらく新しい接続を作成する方法はありますか？

この質問は、perl、apache、Apache::DBI、およびデータベース (MySQL、SQLite など) を使用する Web ベースのアプリケーションに関するものです。

永続的なデータベース接続を作成するために Apache::DBI が使用されることはわかっています。これらの接続は、Apache Web サーバーが起動してからシャットダウンするまでメモリ内に存在します。

私の質問は次のとおりです: Apache プロセスの開始と終了の間の任意の時点で永続的な db 接続を作成することは可能ですか? Apache Web サーバー プロセスの存続期間中、持続的な接続を維持したくありません。

Apache Web サーバーの起動後はいつでも永続的な接続を作成する必要があります。また、Apache Web サーバーがシャットダウンされる前に、永続的な接続をいつでも終了する必要があります。

mod_perl のストレス テスト中に、データベース接続が失われるという問題に遭遇しました。プロセスがデータベース接続を共有しているため、問題が発生していると思われます。

しかし、私は Apache::DBI のすべての指示に従いましたが、これがわかりません。

startup.plではなく、子プロセスで接続を行っています。しかし、DBI->connect から各子によって返された $dbh を調べると、アドレスはすべての httpd プロセスで同じです。まず、これが適切に機能し、プロセスごとに再接続する場合、DBI->connect によって返されるアドレスは子プロセスごとに異なるはずですか? 私はそう仮定していますが、DBI (dbih_setup_handle) のコア C コードがこれを管理しており、同じアドレスを返していることがわかります。ですから、子供の中で再接続することの意味を理解していないのかもしれません.

$dbh ハンドルが同じ場合、適切に再接続していますか?

CentOS 6.4 と PostgreSQL 9.0 で mod_perl2.0.4 / Apache2.2 Web アプリを実行しています。

最近まで、私はこのセットアップを持っていました: Apache::DBI と DBI->connect_cached すべての接続に対して、FATAL: sorry, too many clients already私が唯一のユーザーである私の開発領域でも提供し始めていました。

これをデバッグするために、Apache::DBI へのすべての参照を削除し、最新の DBI にアップグレードし、connect_cached のすべての出現箇所を単純な DBI->connect に置き換えました。今では接続がやや少なくなり、その後離れているように思え<IDLE>ます。しかし、すべてのステートメント ハンドルで disconnect() を呼び出していないことに気付きました。なぜなら、Apache::DBI の下では違いがないように聞こえたからです。

現在、私の接続はすべて同じユーザーとして接続されており、SET SESSION AUTHORIZATION を介してどのユーザーであるかに基づいて権限を下げています。データベースを使用する他の一部のアプリでは、資格情報をデータベースに直接渡すことができるパスワード付きログインが許可されているため、この方法を使用しますが、この特定の Web アプリでは、名前をクリックするだけでログインできるようにするシステムのログイン画面を使用します。したがって、将来のセキュリティに対応していますが、現時点では便利です。また、履歴などのデータベース トリガーは、セッション ユーザーが正しく設定されているかどうかに依存して、誰が何をしたかを追跡します。

間違ったセッション ユーザーでデータベース ハンドルが再利用されることを懸念していたので、{ private_user_login => $login_role_name, PrintError => 0, RaiseError => 1, AutoCommit => 1}connect_cached に渡して、各接続をユーザーごとに区別します。しかし、私は常に接続直後にセッション認証を設定するprivate_user_loginので、特定の Apache プロセスに対して、最終的にはユーザーと同じ数の DB 接続が作成され、アイドル状態のままになる可能性があるように、すべてのハッシュが行うことだと思います。すべてのユーザーは、特定の Apache プロセスをランダムに使用することができます。その間、ハンドルは一切切らないので、そのうち使い切ってしまいます。

私の質問は、すべての接続ハンドルが同じように見えるようにするため、開いたままの接続の数を減らすために を取り出しても安全ですprivate_user_loginか、それとも、接続ハンドルが途中で再利用される可能性があるかということです。別のユーザーが (セッション ユーザーを設定した後に) スクリプトを作成して、競合状態を作成しますか? また、Apache::DBI のドキュメントには呼び出しを削除する 必要はないと書かdisconnect()れていますが、Apache::DBI が切断するかどうかを決定できるように、すべてのスクリプトの最後にそのような呼び出しを行う必要がありますか?

言い換えれば、プライベート接続変数がなければ、次の Apache::DBI->connect() が既存の接続を再利用するとき、SET SESSION AUTHORIZATION の効果は持続しますか? もしそうなら、あるリクエストが現在実行されているが、現在データベースハンドルを使用していない間に、接続が別のリクエストによって再利用される可能性はありますか?

Apache::DBI のドキュメントには次のように書かれています。

Apache::DBI [...] には制限があります: データベース接続をプロセスごとに永続的に保ちます。[...In] すべてのユーザーが一意のユーザー ID を使用してデータベースに接続する高負荷の Web サイト [, e] すべてのサーバーが多数のデータベース ハンドルを作成し、それぞれが新しいバックエンド プロセスを生成します。これにより、短時間で Web サーバーが停止します。

DBIx::Connector のドキュメントではこの制限について言及されていませんが、mod_perl2 コンテキストで DBIx::Connector にも適用されますか?