使用JDBC 3.0实现对嵌套事务的支持 [英] Implementing support for nested transactions using JDBC 3.0

问题描述

我们的遗留应用程序使用JDBC 3.0。它通过实现自己的事务管理器来支持事务，该事务管理器能够为每个线程返回相同的JDBC连接。我最近发现的问题是它不支持嵌套事务：如果事务是在另一个事务中启动的，那么在内部事务的上下文中运行的每个SQL都将使用相同的数据库连接执行，并在提交时或回滚它将自动提交或回滚从外部事务开始的所有更改。

our legacy application uses JDBC 3.0. it supports transactions by implementing its own transaction manager that is capable of returning the same JDBC connection for each thread. The problem I recently discovered is that it doesn't support nested transactions: if a transaction is started inside an another transaction, then every SQLs running in the context of the inner transaction will be executed using the same db connection, and when it's commited or rolled back it will automatically commit or roll back all the changes starting from the outer transaction.

据我所知，我可以使用JDBC 3.0保存点实现对嵌套事务的支持：每当启动嵌套事务时，我都可以为当前连接设置新的保存点。之后，如果嵌套事务被回滚，我将回滚到此保存点。另一方面，如果它被提交，我将什么都不做。只有最外部事务的提交才会保存对数据库的更改。

As far as I understand I can implement the support for nested transaction using JDBC 3.0 savepoints: whenever a nested transaction is started, I can set a new savepoint for the current connection. Afterward, if the nested transaction is rolled back, I will just rollback to this savepoint. If, on the other hand, it is commited, I will just do nothing. Only the commit of the most outer transaction will save the changes to the db.

这是正确的吗？这种方法有什么缺陷吗？如果是的话，我的可能性是什么？

Is this correct? Does this approach have any flaws? If yes, what are my possibilities?

谢谢。

推荐答案

您可以在 Atomikos TransactionsEssentials 中尝试嵌套事务支持。

You could try the nested transaction support in Atomikos TransactionsEssentials.

但是，DBMS中的嵌套事务通常以下列方式受到限制：

However, nested transactions in a DBMS are generally restricted in the following way:

- 您的嵌套事务共享相同的数据库事务，这允许共享以回滚粒度为代价的数据访问（你回滚整个事物）

-either your nested transactions share the same DB transaction, which allows shared data access at the cost of rollback granularity (you rollback the whole thing)

- 或者你的嵌套事务被映射（由Atomikos）到不同的底层数据库事务，代价是不允许对热点数据进行共享数据访问

-or your nested transactions are mapped (by Atomikos) to different underlying DB transactions, at the cost of not allowing shared data access for hotspot data

这种不匹配是由于数据库事务的ACID性质造成的。最终，所有的DBMS访问都必然会发生在这样的数据库事务中。

This mismatch is due to ACID nature of database transactions. Eventually, all your DBMS access is bound to happen in such a database transaction.

如果你想自己包装一些东西，你提到的保存点方法听起来很有希望 - 但是你可能需要确保广泛测试它。

If you want to wrap something up yourself, the savepoint approach you mention sounds promising - but then you would probably need to make sure to test it extensively.

最佳
Guy

Best Guy

这篇关于使用JDBC 3.0实现对嵌套事务的支持的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！