2012-01-10 92 views
0

在我维护的一个asp.net 2.0应用程序中,我们遇到了事务中止错误(超时)的问题。代码失败似乎会导致超时,然后使用transactionscope(默认构造函数)的页面日志记录功能失败(但并非总是)。超时设置为2分钟。事务超时和连接池问题

一些示例代码,类似于我们在我们的应用程序低于:

Try 

     Dim scope As TransactionScope = New TransactionScope(TransactionScopeOption.Required, New TimeSpan(0, 0, CInt(TransactionTimeout))) 

    **A method call that fails is here** 

    Using scope 

**other code is here** 


scope.complete 

end using 


catch 

从我所看到和阅读,是,由于使用块永远达不到我的猜测,交易超时。然后,日志代码(使用任何页面请求完成)尝试登记现有事务,该事务超时并导致事务中止错误(只要调用构造函数)。这个假设是否正确?为什么只有一些请求会失败,并不是全部(假设它们都使用了事务范围)?

我的大问题是连接池如何发挥到这一点?如果用户A击中错误代码,那么用户B是否会受此影响?这是我们见过的行为。如果不是,还有什么可能导致这种情况?我去过MSDN,但是找不到任何真正点击我的事情以及原因。

下面是连接字符串的相关部分:

Enlist=true;Pooling=true;Connection Lifetime=20;Max Pool Size=25;Min Pool Size=5 

FYI。不确定这是否相关,但应用程序使用带有EntLib数据库工厂模式的Oracle 11g数据库。

感谢您的帮助。

回答

1

首先,如果可以的话,我会改变你的代码:

Using scope As New TransactionScope(TransactionScopeOption.Required, New TimeSpan(0, 0, CInt(TransactionTimeout))) 

如果这是不可能的,那么你应该换你的代码在一个try/finally语句,并在最终处置范围如果它被设置。

Dim scope As TransactionScope 
    Try 
     scope = New TransactionScope(TransactionScopeOption.Required, New TimeSpan(0, 0, CInt(TransactionTimeout))) 

     ' **A method call that fails is here** 

     ' **other code is here** 
     scope.complete() 
    Finally 
     If scope IsNot Nothing Then 
      Try 
       scope.Dispose() 
      Catch 
      End Try 
     End If 
    End Try 

但是,连接池可能在超时问题中起作用。

一般来说,连接是由连接字符串键入的,以便后续对相同连接字符串的请求将导致池中的空闲连接,并将相同的连接字符串(如果有)分配给请求。

当连接返回到池时,它将保留在池中达到参数Connection Lifetime中指定的秒数,然后在未重用时释放它。基于

在此,假设你有连接字符串或从连接到连接而变化,如果有超过25个用户在20秒时间间隔执行操作的其它数据在某些用户特定的信息,则没有可用的连接。此外,如果您的应用程序持有的连接打开时间超过绝对必要或未明确关闭它已打开的连接,则连接可能会持续打开的时间比预期长。当TransactionScope未被处置时,情况可能如此。

+0

感谢您的代码更改建议。我们绝对会做出一些改变。你能否确认我对整体问题的理解是否合理 - TransactionScope被实例化,发生错误并阻止scope.complete行被执行,所以连接超时。导致在此事务中登记的后续transactionScope对象立即以超时原因中止。如果这是正确的,连接会发生什么?它留在游泳池吗?这是什么会导致另一个用户得到相同的错误,而不会触及问题代码? – 2012-01-11 13:30:25

+0

你的理解是正确的。我相信会发生的事情是,因为连接永远不会关闭/完成,所以它们永远不会返回到连接池,最终会填满连接池。当池中没有可用的连接时,用户开始超时。 – 2012-01-11 17:41:32

+0

谢谢。我找不到任何能够解释在这种情况下发生的事情。 – 2012-01-13 14:25:54