0

假设我们有一些配置 GUI，其当前形式使用直接 DB 事务以一致的方式为多个可配置组件提交新配置。

现在让我们移动一些 SOAP/WS API 后面的数据 (DB) 内容。GUI 不再有直接的数据库访问权限。事务行为必须保留，但 API 不应设计为明确适应 GUI 表单提交。事实上，我什至不知道新的 GUI 将如何工作或用户输入的结构将如何。因此我需要在 API 服务器端提供类似WS-AtomicTransaction的东西。但是，有（至少）两个警告：

  • GUI 是用 PHP 编写的：我认为 PHP 中没有任何可用的 WS-Transaction 支持。
  • 在等待其他客户端请求时，我不想在服务器端保持数据库事务打开。

我能想到的解决方案：

  • 使用骆驼的聚合。但是，这至少会在两个方面使事情变得更加复杂：
    • 您不能在同一事务内的后续调用中使用新插入行的 DB 行 ID。您需要使用某种符号反向引用，因为在处理聚合消息时客户端和服务器之间没有通信。
    • 呼叫回复不会是立即的（或者对每个单独呼叫的立即和单独回复只是某种存根，即。除了“您的消息已附加到 TX xyz”之外不包含任何有用的信息——如果有的话在骆驼聚合情况下可能）。
  • 前一个解决方案的两个缺点让我想到了请求批处理，其中 WS 标准可能提供了在批处理事务内的后续调用中引用调用结果的方法。有没有这样的东西已经可用？甚至可以作为 PHP 客户端？
  • 试图通过仔细使用行级锁等来消除数据库中的锁争用。但是，当插入新元素时，我的猜测是通常页面和索引页面需要被数据库锁定。
  • 也许一些使用乐观锁定的服务器端持久层？但是同样，如果数据库写入将被推迟到提交（根本不知道这是否可能），那么在最终提交之前不会将任何数据库 ID 返回给客户端。

你怎么看？

4

1 回答 1

0

交易是一种强大的工具，我们很容易进入一种思维模式，在这种模式中，我们将每个问题都视为我们用这把大锤子敲打的钉子。我可以理解你的困惑，因为我自己也经历过。不幸的是，我没有比尝试不考虑事务而是考虑原子 API 调用更好的建议。

当我考虑交易时，我的思维模式通常是这样的：

  • 开始交易
  • 阅读（根据需要重复）
  • 更新（根据需要重复）
  • 提交/回滚

需要一些时间才能意识到我们过度使用了这种模式。实际冲突很少见，并且有许多其他方法可以处理它们。这是API中常用的一个

  • 读取数据并将数据发送到客户端（原子 API 调用）
  • 更新数据（在客户端）
  • 将原始 + 更新发送回服务器（原子 API 调用）
    • 开始交易（在服务器上）
    • 读
    • 与客户原件比较
    • 如果不一样，返回错误（客户端应该重试）
    • 如果相同，更新
    • 犯罪

最后六点是API调用实现的一部分。

Ferenc Mihaly http://theamiableapi.com

于 2012-05-11T18:45:15.567 回答