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

Question

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

我只是想知道切换到非XA JDBC驱动程序是否有任何已知的性能提升-如果没有，可能就不值得切换了？

仅供参考我们使用的是MySQL 5.1

Answer 1

与所有与性能相关的事情一样，答案是:视情况而定。具体来说，这取决于您是如何使用驱动程序的。

与数据库进行事务交互的成本大致分为:代码复杂性开销、通信开销、sql处理和磁盘I/O。

XA和非XA情况下的通信开销略有不同。在其他条件相同的情况下，XA事务在这里需要更多的开销，因为它需要到数据库的更多往返。对于手动提交模式下的非XA事务，至少需要两次调用: sql操作和提交。对于XA，它是start、sql操作、end、prepare和commit。对于您的特定用例，将自动优化为启动、sql操作、结束、准备。并非所有调用的成本都相同:结果集中移动的数据通常占主导地位。在LAN上，额外往返的成本通常不会很高。

然而，请注意，在等待粗心大意的人时，有一些有趣的陷阱。例如，一些驱动程序不支持XA模式下的预准备语句缓存，这意味着XA的使用增加了在每次调用时重新解析SQL的开销，或者需要在驱动程序之上使用单独的语句池。虽然在池的主题上，正确地池化XA连接比池化非XA连接稍微复杂一些，因此根据连接池实现的不同，您可能也会看到一些影响。一些ORM框架特别容易受到连接池开销的影响，如果它们在事务范围内使用激进的连接释放和重新获取。如果可能，请配置为在tx的生命周期内抓取并保持连接，而不是多次命中池。

有了前面提到的关于缓存预准备语句的警告，XA和非XA tx之间的sql处理成本没有实质性差异。然而，db服务器上的资源使用有一个很小的区别:在某些情况下，服务器可能在非XA的情况下更快地释放资源。但是，事务通常足够短，因此这不是一个重要的考虑因素。

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

在前面的几个段落中，我提到了代码复杂性。与非XA相比，XA需要更多的代码执行。在大多数情况下，复杂性都隐藏在事务管理器中，当然，如果您愿意，也可以直接驱动XA。成本大多是微不足道的，取决于前面提到的警告。除非您使用的是一个特别糟糕的事务管理器，在这种情况下，您可能会遇到问题。只读情况特别有趣-事务管理器提供程序通常将其优化工作放在磁盘I/O代码上，而锁争用对于只读用例来说是一个更重要的问题，尤其是在高并发系统上。

还要注意，tx管理器中的代码复杂性在以应用程序服务器或其他标准事务管理器提供程序为特色的体系结构中是一种转移注意力的现象，因为这些服务器或其他标准事务管理器提供程序通常使用相同的代码来进行XA和非XA事务协调。在非XA情况下，要完全忽略tx管理器，您通常必须告诉应用服务器/框架将连接视为非事务性连接，然后使用JDBC直接驱动提交。

因此，汇总是:无论选择XA/非XA，sql查询的成本都将控制只读事务时间，除非您在配置中搞砸了什么，或者在每个tx中执行特别琐碎的sql操作，后者表明您的业务逻辑可能会使用一些重构来更改每个tx中的tx管理开销与业务逻辑的比率。

因此，对于只读情况，通常的事务协议不可知的建议适用:考虑在ORM解决方案中使用支持事务的二级缓存，而不是每次都访问数据库。如果失败，请调优sql，然后增加数据库的缓冲区缓存，直到您看到90%+命中率或服务器的内存插槽最大值，以先出现的为准。只需担心XA和非XA，一旦您这样做了，并发现事情仍然太慢。

Answer 2

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

一个XA事务涉及一个协调事务管理器，一个或多个数据库(或其他资源，如JMS)都包含在单个全局事务中。非XA事务没有事务协调器，所有事务工作都由单个资源自己完成。