JBoss中的XA事務處理緩慢

Question

我們正在運行帶有SQL Server 2005的jboss 4.2.2（sqljdbc驅動程序1.2）。

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

通常，對於任何一個Web請求，瓶頸之一是：

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

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

我正在嘗試確定是否存在以下任何情況：

• 擺脫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進行查詢幾乎可以肯定是過頭的。