假设db中有这样一个表:
id code
a8e09395-771c-4c6b-bb49-4921eeaf3927 2018-1
726b1390-b502-11e8-96f8-529269fb1459 2018-2
7a7ac7a6-b502-11e8-96f8-529269fb1459 2018-3
81758ea6-b502-11e8-96f8-529269fb1459 2019-1
假设有多个客户机正在写入此表。
对于“代码”列,我们希望确保它遵循严格的“今年第n年”模式。
所有客户机应该使用的正确事务隔离级别是什么?
----更新----2018-09-11 11:31:24---------
START TRANSACTION;
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET @code = (SELECT CODE
FROM hey
WHERE id = 123);
UPDATE hey
SET code = @code + 1
WHERE id = 123;
COMMIT;
对上述事务进行了快速测试。
我启动了两个控制台,然后运行上面的代码,我将它们都运行到读取代码列的行。
然后让其中一个更新代码列,它将等待锁定。
然后我让另一个更新代码列,它将死锁并回滚。
现在第一个锁被解除,可以提交了。
所以看起来这种事务隔离可以防止他们互相攻击,对吗?
1条答案
按热度按时间js4nwp541#
你需要用锁定来解决这个问题。
不管事务隔离级别是什么。
在一个会话中:
输出:
在第二个会话中,尝试相同的select for update。它暂停,等待第一个会话的事务持有的锁。
在第一个会话中,使用select返回的值来计算下一个值。然后插入下一行并提交。
第二个会话在第一个会话中的提交之后立即返回。它正确返回新的max代码:
现在第二个会话有了锁,它可以插入下一行,而不必担心任何其他会话会在select和insert之间潜入。
如果使用
FOR UPDATE
锁定行并确保事务连续工作。