并发请求事务以防止不需要的持久性

Posted 2023-02-26

【中文标题】并发请求事务以防止不需要的持久性

【英文标题】：Concurrent requests transaction to prevent unwanted persistence

【发布时间】：2020-12-11 22:00:33

【问题描述】：

我正在努力思考如何解决最初看似“简单”的问题。

我有UserAccounts 可以有很多Purcahses 但业务逻辑指令只能有一个Purchase 处于PurchaseState.IDLE 状态（实体上的一个字段）。 purchase 在首次创建时处于空闲状态。

我有一个 repo，其中有一种方法可以确定用户是否购买了已经存在的给定状态：

boolean existsByPurchaseStateInAndUserAccount_Id(List<PurchaseState> purchaseState, long userAccountId);

我注意到通过一些测试和思考，当两个请求非常接近/同时传递（即并发问题和/或竞争条件）时，我可以创建多个购买。

这会导致用户帐户进行两次购买，并且都处于空闲状态。

我已经绘制了一个快速图表来显示我认为正在发生的事情：

现在，有没有一种使用@Transactional 的方法会导致第二个持久性/事务回滚？ 我不确定是否只是将服务方法包装在@Transcational(isolation=REPEATED_READ) 会缓解这个问题吗？ IE。 SQL 有没有办法以事务方式处理这个问题？

我只能猜测这实际上没有帮助，因为 SQL 事务没有跟踪 existsBy，因此不会回滚？

如果有>1个实体符合条件，那么在方法结束时运行第二个countBy查询以回滚事务是唯一真正的解决方案吗？我仍然不觉得这是“完美的”并完全解决了比赛条件/TX 问题......

所以服务将看到有 2 个实体正在跨两个事务提交（尚未提交），但对于 T2，服务可以抛出 RuntimeException 来触发回滚？

抱歉，我一直在阅读有关事务隔离的信息，但它似乎只适用于说我是否正在检查实体的字段值/列，而不是使用基于“计数（*）”返回的逻辑" 查询...

感谢您的任何启发。

【问题讨论】：

@Turing85 是的，这将是我的理想情况。我做了进一步的谷歌搜索，发现也许我可以在实体的多个字段上添加约束？ ***.com/questions/635937/…

【参考方案1】：

“干净”的解决方案是创建一个专用表user_order_pending，其中包含两列：user_id 和order_id（最好都带有外键约束），并在user_id 上设置唯一约束。然后，在一个事务中，将订单插入orders 和users_order_pending 中的相应条目。如果两个并发事务尝试同时插入新的挂单，只有一个事务会成功，另一个事务会回滚。

如果此更改过于复杂，则还有另一个涉及GENERATED 列的mysql 特定解决方案。我们创建一个新列is_pending，即BOOLEAN，并且可以为空。然后，我们将此列的值设置为true，当且仅当status 列是pending。最后，我们在user_id 和is_pending 列上设置UNIQUE 约束。粗略的草图如下所示：

CREATE TABLE orders (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    status SMALLINT NOT NULL DEFAULT 0,
    is_pending BOOLEAN GENERATED ALWAYS AS (
        CASE
            WHEN status = 0 THEN 1
        END
    ),
    CONSTRAINT unique_user_id_is_pending UNIQUE (user_id, is_pending)
);

在上面的示例中，0 中的 status 代表 pending。现在让我们测试我们的解决方案。首先，我们在表中插入一个新行：

INSERT INTO orders(user_id) VALUES(1);

并检查结果：

SELECT * FROM orders;
+----+---------+--------+------------+
| id | user_id | status | is_pending |
+----+---------+--------+------------+
|  1 |       1 |      0 |          1 |
+----+---------+--------+------------+
1 row in set (0.00 sec)

到目前为止，一切都很好。让我们尝试为该用户添加另一个订单：

INSERT INTO orders(user_id) VALUES(1);
ERROR 1062 (23000): Duplicate entry '1-1' for key 'orders.unique_user_id_is_pending'

这个插入被理所当然地拒绝了，太棒了！现在让我们更新现有条目并赋予它另一个状态：

UPDATE orders SET status = 1 WHERE id = 1;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

再次检查结果：

SELECT * FROM orders;
+----+---------+--------+------------+
| id | user_id | status | is_pending |
+----+---------+--------+------------+
|  1 |       1 |      1 |       NULL |
+----+---------+--------+------------+
1 row in set (0.00 sec)

生成的列已更新，整洁！最后，让我们为user_id 1 的用户插入一个新条目：

INSERT INTO orders(user_id) VALUES(1);
Query OK, 1 row affected (0.01 sec)

果然，我们在数据库中有第二个用户订单：

SELECT * FROM orders;
+----+---------+--------+------------+
| id | user_id | status | is_pending |
+----+---------+--------+------------+
|  1 |       1 |      1 |       NULL |
|  3 |       1 |      0 |          1 |
+----+---------+--------+------------+
2 rows in set (0.00 sec)

由于约束在user_id 和is_pending，我们可以添加新的挂单，例如user_id 2：

INSERT INTO orders(user_id) VALUES(2);
Query OK, 1 row affected (0.01 sec)

---

SELECT * FROM orders;
+----+---------+--------+------------+
| id | user_id | status | is_pending |
+----+---------+--------+------------+
|  1 |       1 |      1 |       NULL |
|  3 |       1 |      0 |          1 |
|  4 |       2 |      0 |          1 |
+----+---------+--------+------------+
3 rows in set (0.00 sec)

最后：由于约束忽略了NULL-values，我们可以将user_id 1 的二阶移动到非挂起状态：

UPDATE orders SET status=1 WHERE id = 3;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

---

SELECT * FROM orders;
+----+---------+--------+------------+
| id | user_id | status | is_pending |
+----+---------+--------+------------+
|  1 |       1 |      1 |       NULL |
|  3 |       1 |      1 |       NULL |
|  4 |       2 |      0 |          1 |
+----+---------+--------+------------+
3 rows in set (0.00 sec)

这个解决方案的好处是，如果数据库处于合法状态，即如果每个用户最多有一个pending 订单，它可以添加到现有数据库中。可以在不破坏现有代码的情况下将新列和约束添加到表中（除了某些进程可能无法在上述场景中插入数据的事实，这是所需的行为）。

【讨论】：

这看起来正是我想要的样子。选项 1 很诱人，因为它是我觉得更“正确”的方式。我会先细读那条路线。这可能意味着某些业务逻辑不可行，可能会与选项 2 一起离开。选项 2 似乎合乎逻辑，也许是我需要的。我不知道我可以有多个这样的约束。我将不得不做一些阅读和一些测试。感谢您的深入回答。我现在快喝了两大杯酒，所以直到星期一才会碰这个哈。谢谢:)。

@Jcov 不要紧张，我的帖子不会去任何地方 :)

毕竟业务需求发生了变化，我还没有实现上述内容。我相信这是有道理的，并且可能是最好的解决方案，所以我接受它，以防其他人遇到类似的问题。