是否可以在一项事务中使用多个持久性单元，而不需要使用 XA？
我们的应用程序需要使用（只读）几个不同的持久性单元指向不同的数据库（以及不同的商业供应商）。
我们没有预算在其中之一 (Sybase) 上启用 2pc。 有没有办法在事务中使用它们而不必是 XA 事务？
我们使用 Websphere 6.1、Sybase 12.5.3、Oracle 10g、Java EE 5 和 JPA 以及 Hibernate Entity Manager。
更新：oracle PU 每月很少更新 1 到 2 次，sybase PU 更新非常频繁——每天多次。 隔离绝对是后者所关心的问题，两者之间的一致性没有必要强制执行。
Our application needs to use (read-only) a couple different persistence units pointing to different databases (different, commercial vendors as well).
We do not have the budget to enable 2pc on one of them (Sybase). Is there a way to use these in a transaction without it having to be an XA transaction?
We're using Websphere 6.1, Sybase 12.5.3, Oracle 10g, Java EE 5, and JPA with Hibernate Entity Manager.
Update: The oracle PU is updated rarely 1 or 2 per month, the sybase PU is updated very frequently -- many times per day. Isolation is definitely a concern for the latter, consistency between the two is not necessary to enforce.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
小心。
只读并不总是意味着 2PC 不适用。 如果您有两个数据库，并且读取两个数据库但只更新一个，则需要事务来保证结果一致。 假设您有一个场景，您读取数据库 A，然后使用这些结果读取并更新数据库 B。如果您未能对数据库 A 使用事务，那么当您的操作处于活动状态时，您读取的数据可能会被删除。数据库 A 可以由另一个应用程序读取和更新。 在这种情况下，您可能会在数据库 B 中获得不一致的数据。
如果您确实正在读取两个数据库并且没有更新两个数据库，那么您可能会再次认为分布式事务及其伴随的锁定是不必要的。 但再一次，也许不是。 如果其他应用程序正在更新相同的数据库，则在这种情况下您也可能会得到不一致的读取。 这取决于您的要求和数据库的其他用户。
我建议阅读隔离级别以获得即使在读取操作期间，也可以深入了解适用于数据库等所有持久存储的锁定。 事务锁定可能是不必要的； 例如，如果您正在处理实际上不会更改的数据（任何应用程序都不会写入），则没有必要。
也许这里有一个商业解决方案 - 与您的供应商协商降低 XA 启用的价格，并支付费用。 随着经济的发展，你可能会得到一份你能负担得起的交易。 旁注：我很惊讶你可以许可数据库但不能获得交易。 我不知道可以通过这种方式获得 Sybase 许可。
Careful.
Read-only does not always mean that 2PC does not apply. If you have two databases, and you read both but only update one, you need a transaction to guarantee consistent results. Suppose you have a scenario where you read database A, then use those results to read and update database B. If you fail to use a transaction with database A, then it is possible that while your operation is active, the data you have read from database A can be read and updated by another application. In this case you can get inconsistent data in database B.
If you truly are reading BOTH databases and updating neither, again you may think that a distributed transaction and its accompanying locking is unnecessary. Once again though, maybe not. You may get inconsistent reads in this scenario as well, if other applications are updating the same databases. It depends on your requirements and the other users of the database.
I would suggest reading up on isolation levels to get some insight into the locking that applies, even during read operations, for all durable stores like databases. Transactional locking may be unnecessary; for example it is unnecessary if you are dealing with data that effectively does not change (no writes by any app).
Maybe there is a business solution here - negotiate with your vendor to drop the price of XA enablement, and pay it. With the economy, you may get a deal you can afford. Side note: I am surprised that you can license a database and NOT get transactions. I was not aware that it was possible to license Sybase in that way.
Atomikos TransactionsEssentials 是一个免费的开源 JTA/XA，带有用于 JDBC（和 JMS）的连接池。
其功能之一是增加了对非 xa 数据源的支持。 如果只读（您的情况），则可以安全且轻松地使用我们的非 xa 数据源将您的 Sybase 包含到 JTA 事务中。
最好的
盖伊
Atomikos TransactionsEssentials is a free, open source JTA/XA with connection pools for JDBC (and JMS).
One of its features is its added support for non-xa datasources. If readonly (your case) it is safe and easy to use our non-xa datasource to include your Sybase into a JTA transaction.
Best
Guy