mybatismysql⾏级锁_mybatis乐观锁实现，解决并发问题银⾏两操作员同时操作同⼀账户就是典型的例⼦。
⽐如A、B操作员同时读取⼀余额为1000元的账户，A操作员为该账户增加100元，B操作员同时为该账户扣除50元，A先提交，B后提交。最后实际账户余额为1000-50=950元，但本该为1000+100-50=1050。这就是典型的并发问题。
乐观锁机制在⼀定程度上解决了这个问题。乐观锁，⼤多是基于数据版本(Version)记录机制实现。何谓数据版本？即为数据增加⼀个版本标识，在基于数据库表的版本解决⽅案中，⼀般是通过为数据库表增加⼀个 “version” 字段来实现。
读取出数据时，将此版本号⼀同读出，之后更新时，对此版本号加⼀。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进⾏⽐对，如果提交的数据版本号⼤于数据库表当前版本号，则予以更新，否则认为是过期数据。
对于上⾯修改⽤户帐户信息的例⼦⽽⾔，假设数据库中帐户信息表中有⼀个version字段，当前值为1；⽽当前帐户余额字段(balance)为1000元。假设操作员A先更新完，操作员B后更新。
a、操作员A此时将其读出(version=1)，并从其帐户余额中增加100(1000+100=1100)。
b、在操作员A操作的过程中，操作员B也读⼊此⽤户信息(version=1)，并从其帐户余额中扣除50(1000-50=950)。
c、操作员A完成了修改⼯作，将数据版本号加⼀(version=2)，连同帐户增加后余额(balance=1100)，提交⾄数据库更新，此时由于提交数据版本⼤于数据库记录当前版本，数据被更新，数据库记录version更新为2。
d、操作员B完成了操作，也将版本号加⼀(version=2)试图向数据库提交数据(balance=950)，但此时⽐对数据库记录版本时发现，操作员B提交的数据版本号为2，数据库记录当前版本也为2，不满⾜ “提交版本必须⼤于记录当前版本才能执⾏更新 “的乐观锁策略，因此，操作员B的提交被驳回。
这样，就避免了操作员B⽤基于version=1的旧数据修改的结果覆盖操作员A的操作结果的可能。
操作员A操作如下：
select id, balance, version from account where id="1";
查询结果：id=1, balance=1000, version=1
updateaccountset balance=balance+100, version=version+1
where id="1" and version=1
select id, balance, version from account where id="1";
查询结果：id=1, balance=1100, version=2
操作员B操作如下：
select id, balance, version from account where id="1";
查询结果：id=1, balance=1000, version=1#操作员A已修改成功，实际account.balance=1100、account.version=2，操作员B也将版本号加⼀(version=2)试图向数据库提交数据(balance=950)，但此时⽐对数据库记录版本时发现，操作员B提交的数据版本号为2，数据库记录当前版本也为2，不满⾜ “提交版本必须⼤于记录当前版本才能执⾏更新 “的乐观锁策略，因此，操作员B的提交被驳回。updateaccountset balance=balance-50, version=version+1
where id="1" and version=1
select id, balance, version from account where id="1";
查询结果：id=1, balance=1100, version=2
jpa mybatis
Hibernate、JPA等ORM框架或者实现，是使⽤版本号，再判断UPDATE后返回的数值

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。