像维基百科、百度百科等如何解决并发的问题,如:A和B同时编辑,A先保存,B后保存,这样的话B就把A编辑的内容覆盖掉了。
如果一个人编辑的时候给记录上锁,防止别的人编辑也比较麻烦,因为A上锁后,他迟迟没有点击保存,这样这个锁得持续好处时间,非好办法
如果靠程序来合并多个用户的编辑结果,这个比较不靠谱
首先问题问的非常好!当学事务的的时候鲜明的例子就是取钱存钱,转账这些,当时特意还写了个sqlserver的事务管理脚本!
不扯蛋,我们来正事:个人认为事务管理很符合你的实际情况!事务的四个特性就是这样体现出来的,概念性问题咱就不探讨了!
数据库的事务和程序的线程有相似的地方:
1.线程之间共享同一片资源,而事务共享的则是数据库内的数据。
2.多线程的意义在于并发执行,提高效率;事务并发执行也能提高程序与数据库交互的效率。
因此如何使用事务与事务相互之间的隔离级别,直接影响了数据库的并发性和数据的准确性。
更新丢失,脏读,不可重复读取,虚读,两次更新问题!这些都是楼主考虑的问题!
隔离级别由低到高(这里楼主google撒概念问题)
现阶段orm框架基本都支持,由其spring事务管理机制确实为开发解决了很大问题!
最后说楼主提到的锁概念!(申明,个人对这个知道点,但是实际场景用运较少,只是谈谈看法)
锁,也是常用的并发控制手段,由其以悲观锁和乐观锁!悲观的楼主讲了,说说乐观滴它的基本思想就是每次提交一个事务更新时,我们想看看要修改的东西从上次读取以后有没有被其 它事务修改过,如果修改过,那么更新就会失败。(因此能够解决第二类丢失修改问题)
完毕!
回家研究研究去,呵呵
我明天在家做个实验,并发处理也挺值得研究的。
@会长:
厉害!good luck,记得告诉我研究结果!哈哈哈~~~~~~~
盖掉就盖掉呗。 根据“开始编辑的时间”和“结束编辑的时间”就可以算出来会不会有冲突。
提示他一下就行了。
TFS不就这么干的么。
提示:你的代码与别人的有冲突。 请检查并merge。如果你确认没问题, 可以强制提交。
比如你可以看下MDN。 他就没有锁。