如何清除 ODP.NET 连接池中的连接错误?
我正在使用 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果您可以使用 odac (odp) 11g,则您已为池设置“验证连接”。它可以在使用之前验证连接。
如果它还不够好 - 你可以尝试 这个 来自 Oracle 的文档。
另外,可能是 这篇文章 会帮助你的。
更新:
正如 @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.
If it will not be good enough - you can try this document from oracle.
Also, may be this post will help you.
Update:
As pointed by @MPelletier, for oracle 12 the link is different.
一般来说,您应该避免尝试操作任何 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.