可靠的 SELECT + UPDATE 的事务与行标记

Question

问题：

给定表 table_a 和 table_b，我需要在 table_a 更新时可靠地（并同时）执行这样的操作：

1. SELECT 来自table_a 的一些行。
2. 在应用程序代码中计算一些东西。
3. UPDATEtable_b 中的一行。

我需要防止发生这种情况（称为场景 A），其中 table_b 最终反映了旧版本的 table_a：

• worker1 从 table_a 获取行。
• table_a 已更新。
• worker2 从 table_a 获取行。
• worker2 更新 table_b。
• worker1 更新 table_b。

但这很好（称之为场景 B）因为table_b 最终处于正确的状态：

• worker1 从 table_a 获取行。
• table_a 已更新。
• worker2 从 table_a 获取行。
• worker1 更新 table_b。
• worker2 更新 table_b。

交易：

一种解决方案是将整个事物包装在REPEATABLE READ 事务中。那么worker1的事务在场景A中失败，worker2的事务在场景B中失败。没有办法区分场景，唯一的选择就是重试失败的事务。

但这在两种情况下都是浪费：在情况 A 中，我们宁愿不重试worker1 的事务，因为table_b 已经完全更新。在场景 B 中，我们一开始就不想让worker2 的事务失败，因为它做的事情是正确的。

行标记：

如果我们从一开始就知道table_b 中行的主键（:b_id）并且每个worker 都有一个唯一的ID（:worker_id），我们可以尝试其他方法。在table_b 中添加mark 列，并让每个工作人员在第1 步之前执行此操作：

UPDATE table_b SET mark = :worker_id WHERE id = :b_id;

然后在第 3 步中添加一个WHERE 子句：

UPDATE table_b SET ... WHERE ... AND mark = :worker_id;

现在worker1 在这两种情况下都不会在步骤 3 中根据需要更新任何行。

行标记在这里是一种合理的方法吗？我缺少什么缺点？这个问题的“规范”解决方案是什么？

澄清：我正在使用 PostgreSQL。

Answer 1

在表 b 上使用事务和 SELECT ... FOR UPDATE。

这将导致行锁定，这将阻止工人 2 更新表 b，直到工人 1 提交。如果您使用 select for update 启动您的工作流程，那么在 worker 1 提交之前，worker 2 无法启动。

第二种方法（可能更好）是将更新包装在一个执行 select 的语句中，因此它是一条语句，并且会自动处理锁定。

需要放弃行标记作为一个想法，因为工人 2 在工人 1 提交之前不会看到标记的行....