多用户同时处理一条数据

场景(问题)描述如下:

0,用户A、B同时打开一个页面,页面显示,客户表T_CUSTOMER字段(C_NAME、C_AGE)

姓名:张三,年龄:25

1,A 将姓名“张三”改为“张三1”,然后保存

2,B 将年龄“25”改为“30”,然后保存

这样A的操作就被覆盖了,姓名又变回“张三”了,大家一般怎么处处这种情况?

这里给出一个较易用的解决方案

给表添加一字段:LAST_UPDATE,即最后更新时间

回放场景

0,用户A、B同时打开一页面,面页显示:

姓名:张三,年龄:25,LAST_UPDATE:2008-10-17 13:45:00

1,A 将姓名“张三”改为“张三1”,然后保存

重点在这里:更新数据时WHERE条件里多一条件:AND LAST_UPDATE = '2008-10-17 13:45:00'

更新成功,此时触发器会将当前时间“2008-10-17 13:46:00”赋值给LAST_UPDATE

2,B 将将年龄“25”改为“30”,然后保存

B更新数据时WHERE条件里也有这个条件:AND LAST_UPDATE = '2008-10-17 13:45:00',但此时LAST_UPDATE的值已经在A修改记录时变成2008-10-17 13:46:00

下面要做的就是给出提示了:喔哟,此信息在你发呆这段时间已被人改过啦,所以你需要返工。

 

 

【问题】在以前的系统开发中,经常遇到一个同样问题,就是多个用户同时并发操作一条记录,这次在交易系统开发过程中,又出现了这样问题。比如交易商A提交单子,由审核人员B审核,此时A正在修改单位,B也正在查看这条记录,A先修改保存后B再审核保存,导致B审核通过的记录不是他所看到的。

【分析】仔细考虑问题,大概分析了三个方法, 并确定了一个可行的方案,可能还有不完善的地方,但解决现有问题还是绰绰有余的。

最先想的是在交易业务代码中用lock对修改方法加锁,运行时注入单例,并且对方法加同步锁,保证了业务数据的正确性, 但是效率低下,用户在使用中不方便,背离了系统可以并发操作的原则。

然后考虑使用悲观锁,这次运行时注入原型,并发操作效率提高, 但是,在同步处理数据库表时又造成锁表,这样并发效率依旧很低。

最后考虑乐观锁, 只是一种数据版本校验机制,它不做数据库层次上的锁定,需要在要并发操作的主表中加入一个"VERSION"字段或者“LASTUPDATETIME”,如果研究过oracle的SCN应该有异曲同工之妙,它的原理是这样:运行时注入原型,这时数据表并不锁住,只是每次update或insert时将VERSION更新, 当下次update,insert时,会校验VERSION,如果不一致,此时提示信息已经修改过了,并且在事务控制下rollback,这样,保证了数据的正确性,并且也不影响并发操作的效率。但是出现的问题是:如果A读了数据,未来及更新,B先更新了数据, 那么他将提交不上数据,因为VERSION已经失效,这样就造成了A重新读取数据,重新填写单据信息。 这也是乐观锁一个缺点,可以在更新前临时保存A填写的数据,再在跳转页中加载这些数据,保证了交易商不用麻烦再次输入这些数据,更新成功则清空这些临时数据

转载于:https://my.oschina.net/u/3774949/blog/3022821

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值