关于数据库的并发控制问题的争论！！--求各位高手评判

Question

   最近一公司在为我单位在B/S平台上做生产调度管理，平台是MySQL4.0+Java。在测试过程中我发现开发人员没有对数据的并发进行控制。即两个人同时修改一条记录时，两个人均可提交，且最后提交人的数据会复盖前面修改人的记录。
    本人对此提出异议后，软件开发人员告之，用生产管理系统中的权限管理，就可解决并发控制的问题！！！
    我从未听说过此类解决方案，为此我们还发生了激烈的争论，请各位高手发言谈谈这个问题。

Answer 1

我觉得更新之前先check一下比较好.但人家说的也对,没有对应权限的角色是不能处理对应的数据信息的.

Answer 2

 在分布式网络环境下，客户端的GIS应用软件可能需要从网络的某个地方获取一定的GIS数据，在传统的二层体系结构下，一般客户端都是从数据库(共享文件)直接读取所需要的数据，而在三层体系结构下，客户端应用程序不再直接访问数据库，而是访问中间件，中间在访问数据库进而传回访问的数据给客户端显示。

Answer 3

我认为由于B/S结构不能象C/S结构那样始终于数据库相连，所数据本身进行并发控制的功能就被虚弱了，故在提交前需要前台程序进行相应判断。而使用任何权限来限制用户的写操作(对同一条记录)，从根本上是无法避免并发产生的！
大家同意我的观点吗？

Answer 4

    我认为由于B/S结构不能象C/S结构那样始终与数据库相连，所以数据库本身进行并发控制的能力就被削弱了，故在提交前需要前台程序进行相应判断。而使用任何权限来限制用户的写操作(对同一条记录)，从根本上是无法避免并发产生的！
    请各位高手发言谈谈这个问题,能否使用程序中的权限管理来避免并发的产生！！

Answer 5

这个和BS CS没有什么关系的
权限管理没有从根本上避免并发产生
只是降低了并发产生的可能

Answer 6

基本同意LZ的看法这个问题只要测试一下就知道了，你建两个用户都赋予同样的权限，然后同时查看并先后修改同一条记录，看看是不是最后提交人的数据会复盖前面修改人的记录对于B/S结构的程序一般采用乐观锁，也就是更新语句里面带版本号的方式来控制，如果发现记录已经被其它用户更新了，则需要提示当前用户

Answer 7

   在C/S中前台开发工具的控件始终与数据库连接着，故出现并发时数据库会自已管理，即使前台不写程序也可实现对并发的控制。
   而在B/S中，前台每次访问完数据库后，与数据库的连接就中断了。故在提交前需由前台程序进行相应判断。
   而使用任何权限来限制用户的写操作(对同一条记录)，从根本上是无法避免并发产生的！！！
   

Answer 8

在C/S中前台开发工具的控件始终与数据库连接着，故出现并发时数据库会自已管理，即使前台不写程序也可实现对并发的控制。
而在B/S中，前台每次访问完数据库后，与数据库的连接就中断了。故在提交前需由前台程序进行相应判断。 
C/S应用同样会有数据库并发控制的问题，与数据库连接是否中断无关而使用任何权限来限制用户的写操作(对同一条记录)，从根本上是无法避免并发产生的！！！ 
同意这一条

Answer 9

参考CSDN上的一篇旧贴：
http://topic.csdn.net/t/20010729/18/214531.html

Answer 10

如果使用权限控制就可以避免并发产生的，那么Oracle、IBM、Sybase都高兴了！并发总算可以不用数据库来管了！！

Answer 11

这个问题还是要看该开发人员所说的生产管理系统中的权限管理具体实现方案是什么。
或许我们孤陋寡闻了？
既然他能这么说，我相信他一定有他的道理，不大可能是敷衍你。只是按照我们对B/S 和C/S构架编程体系的了解，是觉得在B/S结构下仅仅利用权限管理几乎几太可能。
毕竟在B/S下不是实时与数据库连接,无法实现实时判断。
或许可以在每个人访问该数据库后建立一个档案，当其中一人随后修改了数据，
则保存一变量，另外一人提交修改时判断是否在先前一人修改数据库前连接了数据库且可视化界面一直为先前界面。
如果为真，则拒绝再次提交修改。强制重新下载最新数据，提示其是否需要再修改。

Answer 12

1.由于我单位的工作性质是3-5个人在干一个活，即便象开发人员所说的那样每个人只可更改自己的数据，那在现实中也是不可行的。因为在我们的工作中是经常出现数据输入人员不在生产现场的情况。
2.现在的系统中是允许同一用户反复登录系统的！例如用小张的帐户在A机登录时，别人也可使用他的帐户在B机、C机....登录。这样从根本上还是无法避免并发的产生！
3.还有上面提到的管理员并的问题！

Answer 13

我发本贴的目的只是想讨论两个问题： 
  
   1.大家在做MIS时是否对并发进行控制；    2.如果不进行控制，是否使用MIS里的权限管理就可以避免并发的产生。

Answer 14

谢谢zqpsswh ,他说的很对！做系统时主要是看如何满足需求。但是谁来定需求,这个很重要!是由客户来定还是由程序员来定？打个比方：如果我是客户，我肯定要求系统要有较好的可靠性来保证系统中的数据(我们是兵工企业，对数据的准确性要求较高)；但如果我是程序员，肯定会认为并发问题出现的概率太小，即便在程序中不控制也不会对系统造成大的影响。实际上站在哪方说他们都是对的！！关键要看如何去根客户沟通，必定客户是开发人员的衣食父母。做为程序员总不能去跟客户说“并发控制”是选配，而不是标配吧。记得早些年做个台湾厂的项目时他们的老板对我说：“你不用把我们当上帝，但你只要记住--'客户说的永远是对的'，你就能把这个项目做好!”不好意思说了些做项目的感受，有点跑题了。在自己做过的系统中，不管客户是否要求,我们都做了并发控制。请问大家是怎样做的呢？

Answer 15

在该记录的表中加入最后更改时间的字段。
读取数据时，把最后更改时间作为更改表单的一部分（隐藏域，要更安全的话，使用session）。
提交更改时，把表中的对应记录的最后更改时间和提交过来的最后更改时间对比，如果发现时间不对，则提示该记录自从读取出来以后发生了更改。

Answer 16

偶然间发现一个不错的东东，大家有时间也可去测试一下：
     http://aspdemo.nseer.com/erp/home/logind.jsp

Answer 17

需不需要并发控制，主要还是一个取舍权衡的过程，任何项目里面都会存在项目三角形（时间/成本/范围）的博弈，其结果直接影响到项目的质量不赞成为了性能（更高的吞吐量）而牺牲正确性，现在的硬件基本上可以满足绝大部分MIS类型企业应用的需要，为了每次操作快那么几个毫秒而不进行数据完整性和一致性的控制是不明智的，相信任何管理者都不愿意听到软件开发商说：“我们的程序是世界上最快的，就是有时数据可能不准确，不过也没关系，你们DBA手工调整吧”个人认为，对于任何多用户的企业应用系统，在时间和成本允许的前提下，主要功能模块都应该实现并发控制和事务处理。如果受时间和成本的制约，则可以具体分析，对于会有多个用户同时操作一条记录的功能，一定要实现并发控制和事务处理，至于目前不会出现多个用户同时操作一条记录的，则可以暂时不做对于你的问题：
1.大家在做MIS时是否对并发进行控制；  
答案是具体情况具体分析，军工企业的话，个人倾向于需要做2.如果不进行控制，是否使用MIS里的权限管理就可以避免并发的产生。
答案是不能避免（另外，faisun给出的方法就是乐观锁用时间戳的实现方法）

Answer 18

zqpsswh：
 
“楼主在杞人忧天, 现实中只要实现权限控制就基本可以满足需求了 的确会存在并发问题，可惜的是这个问题出现的概率太小 而且就算出现，也并不会对系统的运行结果造成什么影响”这种说法存在根本性错误，“权限”与“并发”控制是完全不同的概念。
权限控制基本属于静态控制，是限制什么人可以读取、修改什么数据，是为了满足业务管理工作、管理流程中固有的限制所需要的。
并发控制属于动态控制，是为了保证数据完整性所必须的，是多用户、并发数据库管理系统基本的要求，是数据库管理系统、应用系统开发人员所必须考虑、实现的，对用户应该是透明的。如果用户数量很少、外人接触不到系统、数据不是很敏感，权限控制是可以没有的；但只要存在不同的人同时存取相同的数据、不管概率有多小，为保证数据的完整性，并发控制都不可少，所谓“而且就算出现，也并不会对系统的运行结果造成什么影响”这种说法太不负责任，作为管理系统，不能保证数据的完整性，还有比这更严重的后果吗？特别是如果真的概率很小，这种系统对用户数据就是一个安全隐患（因为测试、试运行阶段可能根本发现不了问题）