数据库并发一致性案例分析--.doc

　　数据库并发一致性案例分析 　　本文示例源代码或素材下载 　　本部分内容为《数据库原理》课程中的一个课堂案例，幻灯片提供的动画演示有助于理解并发控制的本质，本文内容为幻灯片的摘要。 　　如果你对自己并发控制的能力很有自信的话，读完一、问题提出后直接可以跳转到四、看来问题真不简单处阅读。 　　本文最后给出了部分测试用代码的简单讲解。 　　一、问题提出　　设某银行存款帐户数据如下表： 　　现在要求编写一程序，完成两项功能：存款与取款。每次操作完成后向明细表中插入一行记录并更新帐户余额。 　　二、问题似乎很简单　　解决办法： 　　① 读取最后一行记录的帐户余额数据 　　② 根据存、取款金额计算出新的帐户余额 　　③ 将新的记录插入表中 　　真的这么简单？ 　　在不考虑并发问题的情况下是可行的 　　如果考虑并发，问题就多了（导致余额计算错误！请参考幻灯片与案例代码） 　　三、让我来想一想　　既然存在并发问题，那么解决并发问题的最好办法就是加锁呀！动手试试～～ 　　怎么加锁？加什么锁？ 　　读之前加共享锁？不行！（参考幻灯片） 　　读之前加排它锁？还是不行！（参考幻灯片） 　　当然，问题还不止这些！如何读取最后一行记录？你会发现随着明细记录的增加越来越没效率。 　　四、看来问题真的不是这么简单　　问题出在哪里那？从系统设计一开始我们就走错了！重新设计！ 　　为什么引入冗余数据？ 　　确保帐户余额在唯一的地方进行存储 　　避免了读取帐户余额时访问大量数据并排序 　　新的问题： 　　我们无法直接对数据库进行锁操作 　　必须通过合理的事务隔离级别完成并发控制（ReadUnmitted、Readmitted、RepeatableRead、Serializable），哪一种好呢？ 　　五、着急吃不着热豆腐　　看来我们必须对各事务隔离级别逐一分析 　　① ReadUnmitted 　　显然不行 　　在这个事务隔离级别下连脏数据都可能读到，何况脏帐户余额数据。 　　② Readmitted 　　也不行 　　该隔离级别与二级封锁协议相对应。读数据前加共享锁，读完就释放。前面分析过，此处不再赘述。 　　③ RepeatableRead 　　这个隔离级别比较迷惑人，需要仔细分析： 　　RepeatableRead对应第三级封锁协议：读前加共享锁，事务完成才释放。 　　（过程参考幻灯片，结论：可以避免并发问题，但带来了死锁！） 　　④ Serializable 　　该事务隔离级别在执行时可以避免幻影读。 　　但对于本案例执行效果与RepeatableRead一样（效率低下，成功率低，还有讨厌的死锁！）。 　　似乎走到了绝路 　　经过重新设计后仍然无法让人满意的解决问题！连最高隔离级别都会在高度并发时因为死锁造成很大一部分事务执行失败！ 　　六、绝处逢生　　原因分析 　　死锁的原因是因为读前加S锁，而写前要将S锁提升为X锁，由于S锁允许共享，导致X锁提升失败，产生死锁。 　　解决办法 　　如果在读时就加上X锁，就可避免上述问题（从封锁协议角度这似乎不可能，但确完全可行！） 　　其实SQL Server允许在一条命令中同时完成读、写操作，这就为我们提供了入手点。 　　在更新帐户余额的同时读取帐户余额，就等同于在读数据前加X锁。命令如下： UPDATE Account SET neount = 存取款的金额 BEGIN TRANSACTION Try { UPDATE Account SET neount ount, Balance) VALUES (1, amount, neitted都能确保成功执行 　　写前加X锁，避免了因提升S锁造成死锁的可能 　　实验结果： 　　所有并行执行的事务全部成功 　　帐户余额全部正确 　　程序执行时间同串行执行各事务相同 　　七、事情并没有结束　　还有可优化的余地：网络带宽受到限制时，数据在网络上传输的时间往往比对数据进行读写操作的时间要长。 　　一个典型的更新过程： 　　1、读前加锁 　　2、帐户数据从网上传过来 　　3、修改、插入新记录 1234下一页 这篇文章来自..，。4、将改后的数据通过网络传回去 　　5、数据库提交更新并解锁。 　　如果网速很慢，资源锁定时间就很长。 　　解决办法： 　　使用存储过程，修改后的更新过程： 　　1、将存、取款用到的数据通过网络发给存储过程。 　　2、数据加锁、修改、解锁。 　　3、将结果通过网络回传。 　　将网络延迟放到了事务之外，提高了事务效率。 　　实验结果 　　由于在同一台机器上执行数据库与应用程序，实验结果表明存储过程的执行