背景
我们有一个C#/VB.net客户端应用程序,它使用连接到Oracle数据库的WCF服务。web服务使用.NET框架的Oracle数据提供程序连接到数据库(不要与ODP混淆)。我们的测试人员经历了零星的Oracle帐户锁定,这似乎是在更改用户的Oracle密码后不久发生的。dba_audit_trail日志揭示了在没有任何用户或客户活动的情况下,似乎每隔两分钟就进行一次自动连接的尝试。许多日志(IIS、WCF跟踪、消息记录等)已确认这些连接尝试不是由客户端应用程序直接发起的;它们必须独立于web服务或System.Data.OracleClient库中。自动尝试将永远持续下去,直到web服务的辅助进程(单个工作人员)因不活动而死亡。
在某些情况下,这些自动尝试是在密码更改之前开始的,它们成功地连接到数据库,但一旦密码更改,下一次尝试将失败,导致用户名/密码无效。经过三次尝试,该帐户将被锁定。我们正试图找到这些周期性连接尝试的来源。
我在甲骨文的论坛这里上发现了一个类似的问题,但没有得到解答。
当前思想
我们最近的调查让我们相信,这是来自连接池的意外行为。如果用户在密码更改之前连接到web服务,则将为原始连接字符串创建连接池。在更改密码并重新登录到web服务之后,数据提供程序将根据新的连接字符串创建一个新的连接池。
数据提供程序内部是否有什么东西试图将旧连接从第一个连接池中保存下来?也许第一个连接池正在丢弃旧连接,并试图用一个新连接(现在无效的连接字符串)来补充它。是什么导致的?注意:我们使用的是最小/最大池大小(0/100)的默认设置。
我们不认为我们的代码直接试图从第一个连接池访问连接。用户的会话没有上一次会话密码的任何内存,因此不会使用旧的连接字符串引用第一个连接池。此外,代码中没有任何内容能够解释我们所看到的非常精确的连接间隔。
发布于 2012-10-15 06:23:17
每当发生任何会使连接失效的事件时,您都需要销毁池,以便对泄漏的连接和/或保持池的活动进行适当标记,以防止重复使用。为此,您需要使用数据提供程序的clearpool或clearallpools方法。
http://msdn.microsoft.com/en-us/library/system.data.oracleclient.oracleconnection.clearpool.aspx
此外,全局异常管理器可以侦听为无效用户引发的异常,并通过枚举标识为连接字符串一部分的用户的连接来销毁该池。也许效率不高,但应该能完成任务。
https://stackoverflow.com/questions/12877042
复制相似问题