java - 并发请求事务以防止不必要的持久化

Question

我试图弄清楚如何解决最初看起来“简单”的问题。
我有 UserAccounts可以有很多 Purcahse s BUT 业务逻辑规定只能有一个 Purchase在 PurchaseState.IDLE状态(实体上的一个字段)。一个 purchase首次创建时为 IDLE。
我有一个存储库，其中包含一种方法来确定用户是否购买了已存在给定状态的产品:

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

我注意到一些测试并认为当两个请求非常接近/同时传递时，我可以创建多个购买(即并发问题和/或竞争条件)。
这导致用户帐户有两次购买，并且都具有 IDLE 状态。
我绘制了一个快速图表来显示我认为正在发生的事情:

现在，有没有办法使用 @Transactional 来导致第二个持久性/事务回滚？
我不确定是否只是将服务方法包装在 @Transcational(isolation=REPEATED_READ) 中
会缓解这个问题吗？ IE。 SQL 有没有办法在事务上处理这个问题？
我只能猜测这实际上并没有帮助，因为 SQL 事务没有跟踪existsBy，因此不会回滚？
是运行第二个的唯一真正解决方案 countBy如果有 >1 个实体符合条件，则在方法结束时查询以回滚事务？我仍然不觉得这是“完美的”并完全解决了竞争条件/TX 问题......

因此，该服务将看到有 2 个实体在两个事务中提交(尚未提交)，但对于 T2，该服务可以抛出 RuntimeException 以触发回滚？
抱歉，我一直在阅读有关事务隔离的内容，但它似乎只适用于说我是否正在检查实体的字段值/列，而不是使用基于“count(*)”查询返回的逻辑。 ..
感谢您的任何启发。

Answer 1

“干净”的解决方案是创建一个专用表 user_order_pending有两列:user_id和 order_id (最好都带有外键约束)并在 user_id 上设置唯一约束.然后，在一笔交易中，将订单插入 orders以及 users_order_pending 中的相应条目.如果两个并发事务同时尝试插入新的挂单，则只有一个事务会成功，另一个会回滚。
如果这个改动太复杂，还有一个mysql - 涉及GENERATED的特定解决方案柱子。我们新建一个专栏 is_pending , 那是 BOOLEAN并且可以为空。然后，我们将此列的值设置为 true当且仅当 status列是 pending .最后，我们设置了一个 UNIQUE列约束 user_id和 is_pending .粗略的草图如下所示:

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)
);

在上面的例子中，一个 status的 0代表 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，它可以添加到现有数据库中。每个用户的订单。可以在不破坏现有代码的情况下将新列和约束添加到表中(除了某些进程可能无法在上述场景中插入数据的事实，这是所需的行为)。