Oracle 中的 XAConnection 性能 (10g)
在我们的项目中，我们使用 Oracle XA 连接池。 仅分发一小部分查询（事务）。 其余的都是非常简单的单个数据库修改。
我想知道使用时是否有性能差异 XAConnections 与普通连接的比较。
我们使用websphere v6.1作为服务器。
如果 XAConn 的性能不是很好，那么我计划拥有两个数据源并根据需要使用它们的连接。
任何指示都会有很大帮助。
In our project, we use the Oracle XA Connection pool.
Only a small subset of the queries(transactions) are distributed.
Rest are quite straightforward single database modification.
I would like to know if there is a performance difference in using
XAConnections Vs the normal ones.
We use websphere v6.1 as the server.
If XAConn, is not very performant, then iam planning to have two datasources and use connections from them as appropriate.
Any pointers would be of great help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我没有基准来证实以下内容，这只是“我们都知道”的传统智慧。 与所有性能讨论一样，您的里程会有所不同，如果这对您的应用程序绝对重要，那么您需要执行自己的基准测试。
我相信使用支持 XA 的连接池进行非 XA 工作不会产生显着的性能开销 - 当事务中仅使用单个资源时，WebSphere 会谨慎地使用 1PC 事务。 XA 的主要开销是额外的准备/提交/忘记 XA 消息集，这些在简单的 1PC 情况下不会发生。
因此，主要的危险是无意中启动 2PC 事务。 如果您针对相同的资源执行多项工作，但使用（例如）不同的隔离级别，则可能会发生这种情况。 您从池中获取连接并执行一些工作，该连接现在与您的事务关联，直到提交为止。 您“关闭”连接，名义上将其返回到池中，但实际上 WebSphere 的池会保留您的事务的连接。 您再次请求连接来完成更多工作，只要您请求完全相同的连接，您将再次获得相同的连接，因此工作在单个事务中继续进行 - 我们只有 1PC，没有开销。
我会采取最初拥有一个支持 XA 的池的方法，但有两个单独的资源引用，一个用于 2PC 工作，一个用于 1PC 工作。 让两个引用都指向同一个连接池。 现在，您的代码不再需要单独的连接池，只需重新绑定资源引用（如果您确实需要进行更改）即可。
I have no benchmarks to substantiate the following, this is just "we all know that" conventional wisdom. As with all performance discussions Your Milage Will Vary, if this is absolutely critical to your application then you need to perform your own benchmarks.
I believe that there is no signifincant performance overhead from using an XA-capable connection pool for non-XA work - WebSphere is careful to use 1PC transactions when only a single resource is used in a transaction. The primary overhead of XA is the extra Prepare/Commit/Forget set of XA messages, these will not occur in a simple 1PC case.
So the primary danger is of inadvertantly initiating a 2PC transaction. This can happen if you do several pieces of work supposedly against the same resoruce but with (for example) different isolation levels. You obtain a connection from the pool and do some work, that connection is now associated with your transaction until COMMIT. You "close" the connection, notionally returing it to the pool, but in fact WebSphere's pooling keeps the connection for your transaction. You ask for the connection again to do some more work, provided that you are asking for exactly the same connection you will be given the same connection again and so work continues in a single transaction - we have only 1PC, no overhead.
I would take the approach of initially haveing a single, XA-capable pool, but have two separate resoruce references, one for 2PC work, one for 1PC work. Have both references point to the same connection pool. Your code now is isolated from any need to have separate connection pools, it's just a matter of rebinding the resource-ref if you ever do need to make the change.