【问题标题】:DB2/JDBC database: Possible to join a transaction?DB2/JDBC 数据库:可以加入事务吗?
【发布时间】:2017-07-11 11:47:50
【问题描述】:

我正在开发一个应用程序 A,它启动一个数据库事务,执行一些工作,然后调用远程系统 B,该系统反过来又回调 A。这个 Web 服务调用的处理(在站点 A)还执行一些数据库操作。现在,如果在站点 A 上完成的初始工作以及作为处理站点 A 上的 Web 服务调用的一部分完成的工作都将在同一个数据库事务中完成,这样他们就可以看到彼此的数据,那就太好了他们的更新一起提交/回滚,不会由于游标稳定性等原因导致阻塞。有没有标准的方法来实现这一点?例如,是否可以从打开的事务中提取“事务 ID”,然后将其包含在 Web 服务调用中,并使用该事务 ID“加入”已经打开的事务?还是必须手动实现这样的机制(即在一个框架中管理事务和底层对象,然后可以代表其余代码执行请求,并且可以支持这样的“事务 ID”功能)?这似乎是一个相当普遍的要求,所以我认为可能有一个标准的方法?

【问题讨论】:

    标签: database jdbc transactions db2


    【解决方案1】:

    您所描述的称为分布式事务。它需要一个额外的软件,一个事务管理器 (TM),来处理资源管理器的协调(在这种情况下,DB2 充当资源管理器)。该手册有一个conceptual overview of distributed transactions,以及如何为分布式事务配置 DB2 和应用程序的详细信息。

    从数据库的角度来看,单独的请求(在您的示例中,A 中的初始工作和 B 的回调)仍将启动单独的工作单元,但 TM 将确保它们以原子方式提交或回滚。

    【讨论】:

    • 关于您的最后一句话,这意味着不同的请求不能互相看到,即它们不是真正在同一个事务中运行?如果数据库是为游标稳定性而设置的,那么第一个请求所做的工作实际上可以阻塞表,因为第二个请求完成的只是选择,因为它在不同的事务中运行?
    • 一个工作单元有一个会话(连接)范围,所以是的,不同的连接总是有不同的工作单元,是的,它们有可能相互阻塞。通常,您不希望在外部活动(您对远程系统 B 的调用)期间持有锁,因此您可能需要重新考虑您的实现方法。
    • 太好了,感谢您的澄清。我同意这个设计不是最优的,但是知道正确的方法是重新设计整个流程而不是试图在数据库级别解决它是件好事。
    猜你喜欢
    • 2021-11-20
    • 1970-01-01
    • 1970-01-01
    • 2019-04-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-04-05
    相关资源
    最近更新 更多