XA与非XA JDBC驱动程序的性能？

Question

我们在不需要的情况下使用XA JDBC驱动程序（只读工作不参与分布式事务）。

只是想知道是否有任何已知的性能增益需要切换到Non-XA JDBC驱动程序 - 如果没有，它可能不值得切换？这取决于：我们正在使用MySQL 5.1

Answer 1

与相关的一切事物的表现，答案是

FWIW。具体而言，这取决于你如何使用驱动程序。

与数据库事务性交互的代价大致分为：代码复杂性开销，通信开销，sql处理和磁盘I/O。

XA与非XA情况之间的通信开销略有不同。所有其他条件相同的情况下，XA交易的成本稍高一些，因为它需要更多的往返数据库。对于手动提交模式下的非XA事务，成本至少为两个调用：sql操作和提交。在XA的情况下，它是开始，SQL操作，结束，准备和提交。对于您的特定用例，它会自动优化以启动，sql操作，结束，准备。并非所有调用都具有相同的成本：在结果集中移动的数据通常占主导地位。在局域网上，额外往返的成本通常并不显着。

但请注意，有一些有趣的陷阱潜藏在等待不守规矩的地方。例如，某些驱动程序不支持在XA模式下准备好的语句缓存，这意味着XA使用会带来在每次调用时重新解析SQL的额外开销，或者需要您在驱动程序顶部使用单独的语句缓冲池。虽然就池的话题而言，正确地合并XA连接要比合并非XA连接要复杂一些，因此根据连接池的实现情况，您也可能会看到一些细节。如果某些ORM框架使用主动连接释放并在事务范围内重新获取，则它们特别容易受到连接池开销的影响。如果可能，请配置为在tx的生命周期内抓取并保持一个连接，而不是多次敲击池。

由于前面提到的关于缓存预处理语句的警告，XA和非XA tx之间的SQL处理成本没有实质性差异。然而，数据库服务器上的资源使用情况稍有不同：在某些情况下，服务器可能会在非XA情况下尽早释放资源。然而，交易通常很短，这不是一个重要的考虑因素。

现在我们考虑磁盘I/O开销。这里我们关注的是XA协议引起的I/O，而不是用于业务逻辑的SQL，因为后者在任何情况下都不变。对于只读事务而言，情况很简单：明智的db和tx管理器不会执行任何日志写入，因此没有开销。对于写入情况，由于XA的一个阶段提交优化，数据库是唯一涉及的资源，情况也是如此。对于2PC的情况，每个数据库服务器或其他资源管理器需要两次磁盘写入，而不是非XA情况下使用的写入，而tx管理器同样需要两次。由于磁盘存储缓慢，这是XA与非XA性能开销的主要来源。

后面几段提到了代码的复杂性。 XA比非XA需要更多的代码执行。在大多数情况下，复杂性被埋在交易管理器中，尽管如果您愿意，您当然也可以直接驱动XA。成本大多是微不足道的，但须遵守已提及的注意事项。除非您使用特别差的交易管理器，否则您可能会遇到问题。只读的情况特别有趣 - 事务管理器提供者通常将其优化工作放入磁盘I/O代码中，而对于只读用例而言，锁争用是一个更重要的问题，特别是在高度并发的系统上。

还要注意，tx管理器中的代码复杂性在以应用程序服务器或其他标准事务管理器提供程序为特征的体系结构中是一种红字，因为它们通常对XA和非XA事务协调使用相同的代码。在非XA情况下，为了完全错过tx管理器，通常必须告诉应用程序服务器/框架将连接视为非事务性，然后使用JDBC直接驱动提交。

所以摘要是：你的SQL查询的成本是要称霸只读交易时间无论XA /非XA选择的，除非你弄乱的东西在配置上还是做的特别每个tx中的简单sql操作，后者是您的业务逻辑可能使用某种重构来改变每个tx中tx管理开销与业务逻辑的比率的一个标志。

对于只读情况，通常的事务协议不可知的建议因此适用：在ORM解决方案中考虑事务感知级二级缓存，而不是每次都敲击数据库。否则，请调整sql，然后增加数据库的缓冲区缓存，直到您看到90％的命中率或者您将服务器的RAM插槽中的最大值（以先到者为准）。一旦你做完了，只需要担心XA和非XA，发现事情仍然太慢。

Answer 2

简要解释一下， XA事务是一个“全局事务”。 非XA交易是“本地交易”。

XA事务涉及协调事务管理器，一个或多个数据库（或其他资源，如JMS）都参与单个全局事务。 非XA事务没有事务协调器，并且单个资源本身正在完成其所有事务工作。