如何清除 ODP.NET 连接池中的连接错误?

发布于 2024-11-02 10:03:50 字数 395 浏览 1 评论 0原文

我正在使用 NHibernate 和 ODP.NET 连接到 Oracle 11g 数据库。当然,可能会出现连接错误(网络故障、数据库关闭等)。我正在我的代码中处理所有这些异常,所以没有问题。但是,当然用户可以重试他的操作(也许这只是短暂的网络故障),我的问题就来了:

ODP.NET 默认使用连接池。通常这没有问题,但是当用户在连接错误后重试操作时,NHibernate 会从 ODP.NET 获取无效(池化)连接。用户必须多次重试(直到池为空)才能使其再次工作。

当然,我可以禁用 ODP.NET 中的连接池,但我想避免这种情况。我还阅读了一个设置,该设置检查从池中返回的每个连接与数据库的连接,但这会给每个连接增加额外的往返行程,我也想避免这种情况。

有没有办法配置ODP.NET在任何连接抛出连接异常时自动清除连接池?

I'm using NHibernate and ODP.NET to connect to a Oracle 11g database. Of course there can be connection errors (network failure, DB down, ...). I'm handling all these exceptions in my code, so no problem there. But of course the user can retry his actions (maybe it was just a short network failure), and there comes my problem:

ODP.NET is using connection pooling by default. No problem with that usually, but when the user retries an action after a connection error, NHibernate gets an invalid (pooled) connection from ODP.NET. The user has to retry it multiple times (until the pool is empty) to get it working again.

Of course I can disable connection pooling in ODP.NET, but I'd like to avoid that. I've also read about a setting that checks the connection to the DB for each returned connection from the pool, but this adds an additional round trip to each connection which I'd like to avoid too.

Is there any way to configure ODP.NET to automatically clear the connection pool when any connection throws an connection exception?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

翻了热茶 2024-11-09 10:03:50

如果您可以使用 odac (odp) 11g,则您已为池设置“验证连接”。它可以在使用之前验证连接。

验证连接属性验证来自池的连接。仅当绝对必要时才应使用此属性,因为它会导致数据库往返以在将每个连接提供给应用程序之前立即对其进行验证。如果无效连接并不常见,开发人员可以创建自己的事件处理程序来检索和验证新连接,而不是使用“验证连接”属性。这通常会提供更好的性能。

如果它还不够好 - 你可以尝试 这个 来自 Oracle 的文档。

连接池管理

ODP.NET连接池管理提供显式连接池
控制 ODP.NET 应用程序。应用程序可以显式清除
连接池中的连接。

使用连接池管理,应用程序可以执行以下操作:

注意:.NET 存储过程不支持这些 API。清除
使用 ClearPool 方法从连接池中获取连接。

清除应用程序中所有连接池中的连接
域,使用 ClearAllPools 方法。

当连接从池中清除时,ODP.NET 会重新填充池
具有至少具有设置的连接数的新连接
通过连接字符串中的最小池大小。新连接不
必然意味着池将具有有效的连接。例如,如果
调用 ClearPool 或 ClearAllPools 时数据库服务器已关闭,
ODP.NET 创建新连接,但这些连接仍然存在
无效,因为它们无法连接到数据库,即使
数据库稍后出现。

建议在以下情况之前不要调用 ClearPool 和 ClearAllPools
应用程序可以创建返回数据库的有效连接。
.NET 开发人员可以开发代码来持续检查是否
无法创建有效的数据库连接并调用 ClearPool 或
一旦这是真的,ClearAllPools。

另外,可能是 这篇文章 会帮助你的。

更新
正如 @MPelletier 所指出的,对于 oracle 12 链接不同

If you can use odac (odp) 11g, you have setting Validate Connection for your pool. It can validate the connection before you use it.

The Validate Connection attribute validates connections coming out of the pool. This attribute should be used only when absolutely necessary, because it causes a round-trip to the database to validate each connection immediately before it is provided to the application. If invalid connections are uncommon, developers can create their own event handler to retrieve and validate a new connection, rather than using the Validate Connection attribute. This generally provides better performance.

If it will not be good enough - you can try this document from oracle.

Connection Pool Management

ODP.NET connection pool management provides explicit connection pool
control to ODP.NET applications. Applications can explicitly clear
connections in a connection pool.

Using connection pool management, applications can do the following:

Note: These APIs are not supported in a .NET stored procedure. Clear
connections from connection pools using the ClearPool method.

Clear connections in all the connection pools in an application
domain, using the ClearAllPools method.

When connections are cleared from a pool, ODP.NET repopulates the pool
with new connections that have at least the number of connections set
by Min Pool Size in the connection string. New connections do not
necessarily mean the pool will have valid connections. For example, if
the database server is down when ClearPool or ClearAllPools is called,
ODP.NET creates new connections, but these connections are still
invalid because they cannot connect to the database, even if the
database comes up a later time.

It is recommended that ClearPool and ClearAllPools not be called until
the application can create valid connections back to the database.
.NET developers can develop code that continuously checks whether or
not a valid database connection can be created and calls ClearPool or
ClearAllPools once this is true.

Also, may be this post will help you.

Update:
As pointed by @MPelletier, for oracle 12 the link is different.

拥抱影子 2024-11-09 10:03:50

一般来说,您应该避免尝试操作任何 ADO.NET 提供程序(以及 WCF 通道 - 顺便说一句)的连接池。如果您的应用程序需要在面对底层数据错误(例如超时、池中连接断开等)时具有弹性,那么您应该实现适当级别的事务以确保数据完整性和重试逻辑以重新执行失败的操作。

Generally speaking, you should avoid trying to manipulate the connection pool for any ADO.NET provider (and also WCF channels - an aside). If you application needs to be resilient in the face of underlying data errors (e.g. timeouts, broken connections in pool, etc.) then you should implement the appropriate level of transaction to ensure data integrity and retry logic to re-execute the failed operation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文