问题一:
当事务隔离级别设置为可重复读的时候,将所有select过的行都加了读锁,并且记录了版本号,当update 的时候们如果发现版本号变了,则事务失败回滚。不知道我这样理解是否正确?
问题二:
如果上面的理解正确,那是否innodb的可重复读这个隔离级别已经帮我们实现了乐观锁,所以并不需要手动通过版本或者时间戳来实现乐观锁,或者使用 悲观锁了?
问题三:
悲观锁 select ... for update 是增加了一个写锁? 所以所有的读写都会被block住?
问题四:
假设有事务A,先select 然后 update,事务B同样也是先select 然后再update
如果事务隔离级别为可重复读,事务A,B先后select加上了读锁,那么会不会因此而后面的update操作会互相block住,导致死锁?
问题一和问题四好像是矛盾的,因为如果问题四成立,事务会block住,也不会修改成功导致版本号不一致导致 回滚了。
当事务隔离级别设置为可重复读的时候,将所有select过的行都加了读锁,并且记录了版本号,当update 的时候们如果发现版本号变了,则事务失败回滚。不知道我这样理解是否正确?
问题二:
如果上面的理解正确,那是否innodb的可重复读这个隔离级别已经帮我们实现了乐观锁,所以并不需要手动通过版本或者时间戳来实现乐观锁,或者使用 悲观锁了?
问题三:
悲观锁 select ... for update 是增加了一个写锁? 所以所有的读写都会被block住?
问题四:
假设有事务A,先select 然后 update,事务B同样也是先select 然后再update
如果事务隔离级别为可重复读,事务A,B先后select加上了读锁,那么会不会因此而后面的update操作会互相block住,导致死锁?
问题一和问题四好像是矛盾的,因为如果问题四成立,事务会block住,也不会修改成功导致版本号不一致导致 回滚了。