多用户环境下新手常犯的一个错误

软件开发人员参与的项目从单用户单机版已经变成了多用户环境了，很多新手并没有真正理解多用户环境下要注意的问题；经过一些实践后基本都掌握了书写代码和开发的技巧，但有一个错误出现的概率非常之大。

概括的说就是“认为任务所操作的资源是我独占的”。

下面举一个例子：如果有一个业务它有三种状态“A、B、C”，当业务处于A状态时业务可以被删除；开发删除功能时，先从数据库检索A状态的数据，并以列表方式显示在屏幕上，选择要删除的数据，并在服务器端执行删除。

容易发生错误的地方：新手会将被选中数据的主键传递到服务器端，并在服务器端执行删除时使用 delete From XXX where id = 'idparmater'；这样做的问题就是，执行业务操作前数据状态有可能发生变化而导致删除了不允许删除的数据。

为什么新手这么做呢？他的假设是从我显示数据开始，数据没有发生任何变化。

正确的是使用 delete From XXX where id = 'idparameter' and state = 'A'，这样才能保证删除的数据永远处于A状态。

更加普遍的问题是，大家最常碰到的修改数据时发生；我们从服务器取得数据并在界面中修改数据，修改完后提交数据时，数据已经发生了变化。

原则：以业务目标为本，结合已经永久存储的信息和交互所得的信息进行严格的处理，不要假设交互所得得信息和永久存储的信息是一致的。

实现：前面提到的删除是容易实现的，对于修改可能比较麻烦，有几种办法供参考

1、 记录版本时间戳，给予每条数据一个版本号时间戳，每次更新要比较我获取数据时的时间戳，如果不一致表示我在交互期间，已经有人修改过数据。

2、 比较数据内容，就是进行修改时需要比较我取数时的内容和我更新时的内容要一致，这也是DataSet自动处理更新时采用的办法；这个办法的优势是可以部分控制版本，也就是只对我关注的部分而不是全部进行版本控制，劣势是所需要的Sql语句很麻烦需要相应的工具支持

3、 进行行锁，使用数据库行锁是不现实的，只能使用应用级的行锁；他的问题是异常情况需要进行维护性解锁。

 

这么啰嗦并不是要解决问题，是想强调必须要有一个意识：我们编写的这个功能点执行时所用的数据它不是静止的，一个业务单元存续期间数据内容可能已经发生了变化；任何时候都要有应付提交业务执行时变化的机制。

对于传统多线程开发人员，数据也存在类似的问题，这方面的意识可能强点。

再次强调：这种原因导致的问题会比较隐蔽，除非测试人员很有经验才能发现；很多时候表现为偶发性，而且同一问题表现多种多样的现象，不去研究代码很难发现问题的本质。

 

希望引起重视！！！少一点 “不可能啊…. ,我这不能重现…”等等回答，这种回答有相当一部分是上面说的问题，你的开发代码、测试建立在假设之上的，当然“不可能啊…. ,我这不能重现…”。