并发请求事务以防止不必要的持久化
Concurrent requests transaction to prevent unwanted persistence
我正在努力思考如何解决最初看起来“简单”的问题。
我有 UserAccounts
可以有很多 Purcahse
但业务逻辑规定只能有一个 Purchase
处于 PurchaseState.IDLE
状态(实体上的一个字段) . purchase
首次创建时处于空闲状态。
我有一个回购协议,它有一种方法可以确定用户是否购买了给定状态已经存在的商品:
boolean existsByPurchaseStateInAndUserAccount_Id(List<PurchaseState> purchaseState, long userAccountId);
我注意到通过一些测试并认为当两个请求同时在关闭 proximity/at 中传递时我可以创建多个购买(即并发问题 and/or 竞争条件)。
这导致用户帐户有两次购买,并且都处于闲置状态。
我画了一个快速图表来展示我认为正在发生的事情:
现在,有没有一种使用@Transactional 会导致第二个persistence/transaction 回滚的方法?
我不确定是否只是将服务方法包装在 @Transcational(isolation=REPEATED_READ)
中
会缓解这个问题吗? IE。有没有办法 SQL 处理这个事务?
我只能猜测这实际上没有帮助,因为 existsBy 没有被 SQL 事务跟踪,因此不会回滚?
运行 的唯一真正解决方案是在方法末尾进行第二个 countBy
查询,以便在有 >1 个符合条件的实体时回滚事务?我仍然觉得这不是“完美”并完全解决了比赛 condition/TX 问题...
所以服务会看到有 2 个实体在两个事务中被提交(尚未提交)但是对于 T2 服务可以抛出 RuntimeException 来触发回滚?
抱歉,我一直在阅读有关事务隔离的内容,但它似乎只适用于说我是否正在检查实体的字段 value/column,而不是使用基于 return 的逻辑] 的“count(*)”查询...
谢谢指教
一个“干净”的解决方案是创建一个专用的 table user_order_pending
两列:user_id
和 order_id
(最好都带有外键约束)并在 user_id
上设置唯一约束。然后,在一笔交易中,将订单同时插入 orders
和 users_order_pending
中的相应条目。如果两个并发事务同时尝试插入新的挂单,则只有一个事务成功,另一个事务回滚。
如果此更改过于复杂,还有另一个涉及 GENERATED
列的 mysql
特定解决方案。我们创建一个新列 is_pending
,它是一个 BOOLEAN
并且可以为空。然后,当且仅当 status
列为 pending
时,我们将此列的值设置为 true
。最后,我们在 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
。现在让我们测试我们的解决方案。首先,我们在 table:
中插入一个新行
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
值,我们可以将 user_id 1
的第二个订单移动到 not-pending 状态:
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
订单,则可以将其添加到现有数据库中。可以在不破坏现有代码的情况下将新列和约束添加到 table(除了某些进程可能无法在上述场景中插入数据这一事实之外,这是所需的行为)。
我正在努力思考如何解决最初看起来“简单”的问题。
我有 UserAccounts
可以有很多 Purcahse
但业务逻辑规定只能有一个 Purchase
处于 PurchaseState.IDLE
状态(实体上的一个字段) . purchase
首次创建时处于空闲状态。
我有一个回购协议,它有一种方法可以确定用户是否购买了给定状态已经存在的商品:
boolean existsByPurchaseStateInAndUserAccount_Id(List<PurchaseState> purchaseState, long userAccountId);
我注意到通过一些测试并认为当两个请求同时在关闭 proximity/at 中传递时我可以创建多个购买(即并发问题 and/or 竞争条件)。
这导致用户帐户有两次购买,并且都处于闲置状态。
我画了一个快速图表来展示我认为正在发生的事情:
现在,有没有一种使用@Transactional 会导致第二个persistence/transaction 回滚的方法?
我不确定是否只是将服务方法包装在 @Transcational(isolation=REPEATED_READ)
中
会缓解这个问题吗? IE。有没有办法 SQL 处理这个事务?
我只能猜测这实际上没有帮助,因为 existsBy 没有被 SQL 事务跟踪,因此不会回滚?
运行 的唯一真正解决方案是在方法末尾进行第二个 countBy
查询,以便在有 >1 个符合条件的实体时回滚事务?我仍然觉得这不是“完美”并完全解决了比赛 condition/TX 问题...
所以服务会看到有 2 个实体在两个事务中被提交(尚未提交)但是对于 T2 服务可以抛出 RuntimeException 来触发回滚?
抱歉,我一直在阅读有关事务隔离的内容,但它似乎只适用于说我是否正在检查实体的字段 value/column,而不是使用基于 return 的逻辑] 的“count(*)”查询...
谢谢指教
一个“干净”的解决方案是创建一个专用的 table user_order_pending
两列:user_id
和 order_id
(最好都带有外键约束)并在 user_id
上设置唯一约束。然后,在一笔交易中,将订单同时插入 orders
和 users_order_pending
中的相应条目。如果两个并发事务同时尝试插入新的挂单,则只有一个事务成功,另一个事务回滚。
如果此更改过于复杂,还有另一个涉及 GENERATED
列的 mysql
特定解决方案。我们创建一个新列 is_pending
,它是一个 BOOLEAN
并且可以为空。然后,当且仅当 status
列为 pending
时,我们将此列的值设置为 true
。最后,我们在 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
。现在让我们测试我们的解决方案。首先,我们在 table:
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
值,我们可以将 user_id 1
的第二个订单移动到 not-pending 状态:
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
订单,则可以将其添加到现有数据库中。可以在不破坏现有代码的情况下将新列和约束添加到 table(除了某些进程可能无法在上述场景中插入数据这一事实之外,这是所需的行为)。