我们正在运行带有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 在其中一个项目上花费了几百毫秒（在某些情况下几秒钟）。累计大部分响应时间花在这些项目上。
我正在尝试识别是否存在以下任何一种情况：
答案 0 :(得分：1)
如果您在单个事务中针对多个资源执行工作，则必须执行XA事务，如果您需要一致性，则需要XA。但是，您正在谈论“查询”，这可能意味着您主要是在进行只读活动，因此XA可能过度。此外，您不会谈论使用多个数据库或其他事务资源，所以您真的需要XA吗？
第一步：了解需求，您是否需要跨越多个数据库交互的事务范围？如果您只是执行单个查询，则不需要XA。如果你有混合需要XA的简单活动和不需要XA的简单查询，那么使用两个不同的连接，一个是XA而另一个没有 - 这说明了你的意图。但是我希望XA驱动程序能够使用单一资源优化，这样如果不需要XA，你就不需要支付管理费用，所以我怀疑这里有更多的东西。 （免责声明我不使用JBoss，所以我的直觉是可疑的。）
因此，请查看您的事务范围是否合适，隔离级别是否合理等等。您是否因为交易过长而无法进行争用，例如交易是否超出了用户的思考时间？
接下来那些多秒等待：这意味着争用（或一些奇怪的网络问题）我认为xa_start缓慢的唯一原因是写一个事务日志花费的时间太长了 - 你的日志是否有些慢网络设备？等待getConnection（）可能只是暗示你的连接池太小（或者你连接的时间太长）如果xa_commit和xa_end花了很长时间我想知道资源管理器在做什么，你能不能从数据库服务器获取任何信息。
我的整体立场：如果你真的需要XA，那么你将支付一些日志记录和网络消息开销，但这些不应该花费你数百或数千毫秒。大多数业务系统在其整体资源访问的一小部分中需要XA，通常在更新两个独立的系统时，并且几乎从不在只读方案中 - 跨分布式系统的绝对一致性几乎没有意义，因此使用XA进行查询几乎肯定是过度的。