2012-01-10 140 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