JBoss中緩慢的XA事務

Question

我們使用SQL Server 2005（sqljdbc驅動程序1.2）運行jboss 4.2.2。

我們最近安裝了新的文物，可以看到我們的交易大瓶頸。

一般對於任何一個網絡請求的瓶頸坐在其中的一個：

• master..xp_sqljdbc_xa_start
• master..xp_sqljdbc_xa_commit
• org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection()
• master..xp_sqljdbc_xa_end

幾百毫秒花在這些項目之一（在某些情況下，幾個seco NDS）。累積的大部分響應時間都花費在這些項目上。

我想indentify是否其任一操作：

• 威爾移動從XA交易走幫助嗎？
• 在我的數據庫中有沒有更大的問題，我沒有知名度？
• 我可以升級我的SQL驅動程序來幫助嗎？
• 或者這是一個跡象表明只有很多查詢，我們應該從查看我們的代碼開始，並嘗試降低總體查詢的數量？

Answer 1

如果您在單個事務中針對多個資源執行工作，並且需要一致性，那麼您需要XA，XA事務是必需的。然而，你正在談論「查詢」這可能意味着你主要在做只讀活動，所以XA可能是矯枉過正的。此外，你不會談論使用多個數據庫或其他事務資源，所以你真的需要XA嗎？

所以第一步：瞭解需求，你需要跨越多個數據庫交互事務範圍？如果你只是做一個單一的查詢，那麼XA是不需要的。如果您需要XA的活動以及不需要XA的簡單查詢混合使用，請使用兩個不同的連接，一個使用XA，一個不使用 - 這說明了您的意圖。不過，我希望XA驅動程序使用單一資源優化，以便如果不需要XA，則不需要支付開銷，所以我懷疑這裏正在發生更多事情。 （免責聲明我不使用JBoss，所以我的直覺是可疑的）。

所以看看，看看你的事務範圍是否適當，隔離級別是明智的，等等。您是否因爲交易不合理而導致爭用，例如，是否在用戶的思考時間進行交易？

接下來的那些多秒的等待：這意味着爭用（或者一些離奇的網絡問題）我能想到的xa_start變慢的唯一原因是編寫一個事務日誌需要的時間過長 - 你的日誌可能在一些網絡設備慢？等待getConnection（）可能僅僅意味着您的連接池太小（或者您連接的連接時間太長）如果xa_commit和xa_end需要很長時間，我想知道資源管理器在做什麼，您能不能從數據庫服務器獲取任何信息。我的整體位置：如果你真的需要XA，那麼你將支付一些日誌和網絡消息開銷，但這些開銷不應該花費你幾百或幾千毫秒。大多數業務系統需要在整個資源訪問的一小部分時間內使用XA，通常在更新兩個獨立的系統時幾乎從不進行只讀場景 - 分佈式系統之間的絕對一致性幾乎沒有意義，因此使用XA進行查詢幾乎肯定是矯枉過正的。