我们运行的是jboss 4.2.2和SQL server 2005 (sqljdbc driver 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驱动程序来帮助这个吗?
- 或者这表明有很多查询，我们应该从查看我们的代码开始，并尝试降低查询的总数?
如果在单个事务中对多个资源执行工作，则需要XA事务，如果需要一致性，则需要XA。但是，您谈论的是"查询"，这可能意味着您主要是在执行只读活动，因此XA可能是多余的。此外，您没有谈到使用多个数据库或其他事务资源，因此您真的需要XA吗?
第一步:了解需求，您是否需要跨多个数据库交互的事务作用域?如果您只执行单个查询，则不需要XA。如果混合了需要XA的活动和不需要XA的简单查询，那么使用两个不同的连接，一个带XA，一个不带XA——这就澄清了您的意图。然而，我希望XA驱动程序使用单一资源优化，这样如果不需要XA，您就不必支付开销，所以我怀疑这里还有更多的事情要做。(免责声明:我不使用JBoss，所以我的直觉是可疑的)。所以看看你的事务范围是否合适，隔离级别是否合理等等。您是否因为事务长得不合理而产生争用，例如，事务是否超过了用户的思考时间?
接下来是那些多秒钟的等待:这意味着争用(或一些奇怪的网络问题)我能想到的xa_start慢的唯一原因是写事务日志花费了不合理的长时间-您的日志可能是在一些慢速的网络设备上吗?等待getConnection()可能仅仅意味着您的连接池太小(或者您保持连接的时间太长)如果xa_commit和xa_end花费了很长时间，我想知道资源管理器正在做什么，您能从数据库服务器获得任何信息吗?
我的总体立场是:如果您确实需要XA，那么您将支付一些日志记录和网络消息开销，但这些不应该花费您数百或数千毫秒。大多数业务系统在其整体资源访问的一小部分中需要XA，通常是在更新两个独立的系统时，在只读场景中几乎从不需要XA——跨分布式系统的绝对一致性几乎没有意义，因此在查询中使用XA几乎肯定是多余的。