提交 JTA 事务后可以回滚吗?

发布于 2024-10-13 23:12:37 字数 316 浏览 5 评论 0原文

我有一个已提交的 JTA 交易。提交后可以回滚吗?如果是,怎么办?我有以下情况。

  1. 我有一个更新了 3 个数据库的后端层。我已经使用了 JTA 用户交易。如果任何数据库中的更新失败,则使用 utx.rollback 回滚对 3 个数据库的所有更新

  2. 现在,我在后端层之上有一个层,用于更新其他一些数据库。现在我希望步骤 1 和步骤 2 都成功或都失败,因此我想回滚步骤 1 的 JTA 事务,以防步骤 2 失败。

我很难将步骤 2 的代码放入步骤 1 中,因为我们在步骤 2 中使用一些现有的 API 来更新数据库。

I have a JTA transcation which I commit. Can I roll it back after I commit? If yes, how? I have following situation.

  1. I have a backend layer which updated 3 DBs. I have used JTA user transcation for it. If update in any DB fails all updates to 3 DBs are rolled back using utx.rollback

  2. Now I have a layer on top of backend layer which updates some other DB. Now I want that step 1 and step 2 should both succeed or both fail, so I want to roll back JTA transcation of step 1 in case step 2 fails.

It's difficult for me to put code of step 2 into 1 as we are using some existing APIs to update DB in step 2.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

岁月静好 2024-10-20 23:12:40

据我所知,您无法回滚已提交的事务。底层数据库将不支持它。例如,oracle 将不允许已提交的事务回滚。

当然有一种方法可以恢复到之前的状态,术语称为“时间点恢复”。 Oracle的时间点恢复机制称为FlashBack。

http://download.oracle.com/docs/cd /B28359_01/appdev.111/b28424/adfns_flashback.htm

这将允许您将数据库状态恢复到以前的快照。

但问题是,没有 JTA 接口来执行此操作。 (事实上​​,它超出了事务管理器的范围。)

最好的选择是在事务中注册保存点,而不提交并在一个或多个操作失败时回滚到保存点。

As far as I know you cannot rollback a committed transaction. The underlying database will not support it. For instance oracle will not allow committed transaction to rollback.

Of course there is a way to return to previous state and the terminology is called "point in time recovery". Oracle's point in time recovery mechanism is called FlashBack.

http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_flashback.htm

This will allow you to revert your database state to a previous snapshot.

But the catch is, there is no JTA interface to perform this. (Infact it is outside the scope of Transaction Manager.)

The Best bet is to register savepoints in your transaction without committing and rolling back to the save point if one or more operation fails.

渔村楼浪 2024-10-20 23:12:40

您无法回滚已提交的事务,无论它是 XA 事务还是非 XA 事务。

为了解决您提到的问题,必须将所有涉及的资源包含在单个 XA 事务中。

如果由于某种原因上述解决方案不可行,您可以这样做:
a) 要求第一层(3 个 DB)准备。
b) 如果 (a) 的结果正常,则提交第四个 DB。
c) 如果 (b) 的结果正常,则调用 3 个 DB 上的第二阶段提交。

HTH。

谢谢,
镍丁

You cannot rollback a committed transaction, whether it is an XA transaction or nonXA one.

To solve the problem you mentioned, one has to include ALL involved resources inside a single XA transaction.

If the above solution is not feasible for some reason, you can do this:
a) Ask the first layer (of 3 DBs) to prepare.
b) If outcome of (a) is OK, do a commit of the 4th DB.
c) If outcome of (b) is OK, call the second phase commit over the 3 DBs.

HTH.

Thanks,
Nitin

最笨的告白 2024-10-20 23:12:39

我认为答案是你不能使用 JTA 或其他 RDBM 做这样的事情。

事务要么被提交,要么被回滚。一旦成功提交,它们就无法回滚。

唯一可能的“出局”可能是尝试使用嵌套事务,并回滚外部事务。但这可能行不通:

  • 并非所有 JTA 实现都支持嵌套事务。
  • 即使他们这样做了,也不能保证外部事务会成功提交。这可能会让您提交“其他”数据库并回滚 JTA 事务。

听起来您将不得不重新考虑您的持久性 API。

I think that the answer is that you cannot do anything like this using JTA, or other RDBMs.

Transactions are either committed, or they are rolled back. Once successfully committed they cannot be rolled back.

The only possible "out" might be to try and use nested transactions, and rollback the outer transaction. But that probably isn't going to work:

  • Not all JTA implementations support nested transactions.
  • Even if they did, there is no guarantee that the outer transaction will successfully commit. And that could leave you with the "other" DB committed and the JTA transaction rolled back.

It sound like you are going to have to rethink your persistence APIs.

反目相谮 2024-10-20 23:12:37

事务提交后无法回滚。

You can't rollback a transaction after it is committed.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文