问题标签 [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 属性。，

这是原始代码：

我用于重新连接的代码：

有没有一种安全的方法来使用 Apache::DBI 和分叉？有没有办法让它创建一个新的连接？

这个问题与我们基于 Web 的应用程序有关，该应用程序使用 perl、apache、Apache::DBI 和数据库（MySQL、SQLite 或任何东西）。

我们知道 Apache::DBI 用于创建持久的数据库连接。从 Apache Web 服务器启动到关闭，这些连接一直存在于内存中。

我的问题是：是否可以在 Apache 进程的开始和结束之间的任意时间创建持久的数据库连接？我们不希望在 Apache Web 服务器进程的整个生命周期中都有持久连接。

我们需要在 Apache Web 服务器启动后的任何时候创建持久连接。我们需要在 Apache Web 服务器关闭之前的任何时候结束持久连接。

在对数据库连接消失的 mod_perl 进行压力测试时，我遇到了一个问题。我怀疑进程正在共享数据库连接，从而导致了问题。

但是我已经遵循了 Apache::DBI 的所有说明，但无法弄清楚这一点。

我在子进程中而不是在 startup.pl 中建立连接。但是当我检查每个子进程从 DBI->connnect 返回的 $dbh 时，每个 httpd 进程的地址都是相同的。首先，如果这工作正常并为每个进程重新连接，那么 DBI->connect 返回的地址对于每个子进程是否应该不同？我假设是这样，但据我所知，DBI 中的核心 C 代码（dbih_setup_handle）正在管理它并返回相同的地址。所以也许我不明白重新连接孩子意味着什么。

如果 $dbh 句柄相同，我是否可以正确重新连接？

我有一个 mod_perl2.0.4 / Apache2.2 Web 应用程序在 CentOS 6.4 和 PostgreSQL 9.0 上运行。

直到最近，我才进行了这样的设置FATAL: sorry, too many clients already： Apache::DBI 和 DBI->connect_cached 用于所有连接，即使在我是唯一用户的开发区域中，它也开始提供。

为了调试它，我删除了对 Apache::DBI 的所有引用，升级到最新的 DBI，并将所有出现的 connect_cached 替换为普通的 DBI->connect。现在在我看来，建立的联系少了一些，然后就离开了<IDLE>。然而，我意识到我并没有在我的所有语句句柄上调用 disconnect()，因为它听起来像在 Apache::DBI 下它不会产生任何影响。

我的连接当前以同一个用户的身份连接，然后通过 SET SESSION AUTHORIZATION 降低他们的权限。我这样做是因为其他一些使用数据库的应用程序允许密码登录，这可以将凭据直接传递给数据库，但是这个特定的网络应用程序使用荣誉系统登录屏幕，您只需单击您的姓名即可登录。因此，它目前已为未来的安全做好准备，但也提供了便利。此外，历史等数据库触发器依赖于正确设置会话用户来跟踪谁做了什么。

因为我担心数据库句柄被错误的会话用户重用，所以我传递{ private_user_login => $login_role_name, PrintError => 0, RaiseError => 1, AutoCommit => 1}给 connect_cached 以按用户区分每个连接。但是由于我总是在连接后立即设置会话授权，所以我认为所有private_user_login哈希所做的都是使对于给定的 Apache 进程，如果最终创建和闲置的数据库连接数可能至少与用户数一样多每个用户都设法随机使用给定的 Apache 进程。同时，因为我没有断开任何手柄，它们最终会用完。

我的问题是，取出private_user_login使所有连接句柄看起来相同，减少打开的连接数量是否安全，或者是否有可能在中间重新使用连接句柄脚本（在设置会话用户之后）由不同的用户，从而创建一个竞争条件？此外，尽管 Apache::DBI 的文档说我不需要删除 disconnect()调用，但我是否应该在每个脚本的末尾都有这样的调用，以便 Apache::DBI 可以决定是否断开连接？

换句话说，如果没有我的私有连接变量，当下一个 Apache::DBI->connect() 重用现有连接时，SET SESSION AUTHORIZATION 的效果是否仍然存在？如果是这样，当一个请求当前正在执行但当前未使用数据库句柄时，是否有可能另一个请求重新使用连接？

Apache::DBI 的文档说：

Apache::DBI [...] 有一个限制：它在每个进程的基础上保持数据库连接的持久性。[...在]一个负载很重的网站中，每个用户都使用唯一的用户 ID 连接到数据库[，每个服务器都会创建许多数据库句柄，每个句柄都会产生一个新的后端进程。在很短的时间内，这将杀死 Web 服务器。

DBIx::Connector 的文档没有提到这个限制，但是在 mod_perl2 上下文中它是否仍然适用于 DBIx::Connector？

我有Apache::DBI->connect_on_init($dsn, $user, $passwd);在 PerlRequire 加载的脚本中执行的 mod perl 2 代码。

但是在处理请求时，所做DBI->connect_cached($dsn, $user, $passwd)的是创建一个额外的连接，而不是使用在子初始化时创建的连接。（使用 DBI 代替 Apache::DBI 因为该代码也用于非 apache 上下文。）

如何让它使用已经缓存的连接？