数据库并发操作中丢失更新现象的研究
2014-10-10周薇
周薇
摘要： 丢失更新（lost update）是一个经典的数据库问题，在多用户计算机环境中存在。作为一名数据库开发者，通过感同身受的例子，向大家展示何为丢失更新现象，并对这种现象进行一定的研究。同时，提出几种防止的策略。
关键词：数据库；丢失更新；防止策略
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2014）24-5593-02
Lost Update Phenomena of Research in the Database Concurrency Operations
ZHOU Wei
（Wuxi Institute of Technology， Wuxi 214121， China）
Abstract： Lost update is a classic database problem. It exists in a multi-user computer environment. As a database developer， through empathy example， to show what is lost update phenomenon， and conduct some research this phenomenon. Meanwhile， put forward several prevention strategies.
Key words： database； lost update； prevention strategies
1 概述
当2个或多个用户同时（时间上重叠）编辑同一行数据时会发生丢失更新，特别是在基于Web的应用程序中常常出现。在实际运行过程中，可能在几天甚至几个月中才会出现一次。这种现象只是随机地、零星地出现，而且在受控环境中完全不可再生，对应用程序是致命的。导致开发人员误以为是用户的错误，其实是开发人员在编写应用程序的时候，没有处理好DML命令。
2 丢失更新的现象
丢失更新是指2个或多个事务读取同一数据并进行修改，其中一个事务的修改结果破坏了另一个事务修改的结果。有两类丢失更新：
1） A事务撤销时，把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题。A事务在撤销时，“不小心”将B事务已经转入账户的金额给抹去了。
2） A事务覆盖B事务已经提交的数据，造成B事务所做操作丢失。由于转账事务覆盖了取款事务对存款余额所做的更新，导致银行最后损失了100元，相反如果转账事务先提交，那么用户账户将损失100元。
在此过程中，买家A的“取消”订单的动作，发生丢失。同时，对卖家造成了一定的经济损失。
如何防止买家A的“取消”动作不会丢失，或者卖家的“发货”动作不会丢失呢？下面提出4种策略，加以证明。
4 防止丢失更新的策略
1） 设置数据库的隔离级别为Serializable
当是查询操作的时候添加共享锁，共享锁下被人可以访问同一条记录；当进行修改操作的时候加排他锁，别人不可以修改。内在机制是异常退出机制。
卖家查询订单的时候，给这个订单记录添加了共享锁，买家可以查看。同理，买家查看他的订单的时候，也为自己的记录添加了共享锁，但共享锁下不能再添加排他锁。当卖家想做修改操作（“发货”）的时候，给这个订单记录添加一个排他锁是加不上的，他需要等，等待买家释放了共享锁，也就是提交了事务，这个排它锁才可以加上。但此时，如果买家也想操作这个订单记录，想给他的订单记录添加排他锁，也是不可以的，因为卖家那边已经有了共享锁，买家想操作的话，也必须让卖家去释放这个共享锁。这样，卖家就要等买家，买家也要等卖家。假设，此时买家做了修改的操作，根据共享锁存在的情况下，不能加排他锁的原则，买家那里就会出现异常。此时这个“取消”操作终止，“取消”操作无效。就不会产生“取消”操作的丢失。
2） 悲观锁
一种进行修改的时候，就给这条订单记录加锁，别人就不能再操作了。悲观锁就是程序员认为，客户访问某条记录的时候，很有可能其他人也在访问同条记录。保险起见，为这条订单记录加一把悲观锁，此时其他任何人都不可以修改这条记录。这种锁，适用于更新多查询少的系统。
3） 乐观锁
乐观锁就是指当买家或卖家要修改一条订单记录的时候，不认为会有别人和自己同时操作这条订单记录。可利用至少两种方式实现：
（1） 在订单表中，添加一个version字段，数据类型为identity，表示版本
在修改的的时候利用版本号机制，那么别人的操作会因为版本号的差异而失效。当第一次操作的完毕的时候，这个版本号就自动加1，此时别人如果想要修改这条记录的时候，会因为版本号的原因就不能做修改了。适用于查询多更新少的系统。
（2） 在订单表中，添加一个timestamp字段，数据类型也为timestamp时间戳（类似于邮局的邮戳）
时间戳列中存放的是一个十六进制的数据，不管是买家或卖家的任何操作，都会产生一个唯一的时间戳值。在卖家“发货”或买家“取消”订单的时候，都会检测时间戳值的值有没有发生变化。如果不变，则继续；反之，则操作不能进行。
4） 通过IF语句搭配订单状态的检查，也可防止丢失更新
（1） 假如买家想“取消”订单，操作代码如图3。
（2） 假如卖家想为订单“发货”，操作代码如图4。
图4 发货
这样，不管“取消”、“发货”两个动作发生的先后次序如何，均不会发生“取消”丢失，或“发货”丢失。
5 结束语
在数据库并发操作过程中，如果丢失更新的现象，数据库开发人员在设计的时候，就能考虑全面，那么是完全能够避免的。除
了程序控制外，还有许多工具也可以保护、避免这种情况，如Oracle Forms和HTML DB等。这些工具能确保：从查询记录的那个时刻开始，这个记录没有改变，而且对它执行任何修改时都会将其锁定。为了用户的切身利益，作为一名数据库开发者，将继续研究丢失更新的现象，寻求更多的解决办法。
参考文献：
[1]（美）刘易斯.数据库与事务处理[M]. 1版.北京：机械工业出版社，2005：537-547.
[2] 程云志.数据库原理与SQL Server 2005应用教程[M]. 1版.北京：机械工业出版社，2012：236-240.
[3] 蒋瀚洋，李月军，庞娅娟.SQL Server 2005数据库管理与开发教程[M]. 1版.北京：人民邮电出版社，2009：147-152.
[4] 陆琳，刘桂林.数据库技术与应用-SQL server 2005（应用篇）[M]. 1版.长沙：中南大学出版社，2010：290-295.
[5] 吕鹏.数据库更新丢失解决方案.IT/计算.[2011-08-10].
[6] 孟宪虎，马雪英，邓绪斌.大型数据库管理系统技术、应用与实例分析——基于SQL Server 2005[M]. 2版.北京：电子工业出版社，2011：119-137
[7] 李萍，黄可望，黄能耿.SQL Server 数据库应用及实训[M].1版.无锡职业技术学院，2014：96-102.endprint
摘要： 丢失更新（lost update）是一个经典的数据库问题，在多用户计算机环境中存在。作为一名数据库开发者，通过感同身受的例子，向大家展示何为丢失更新现象，并对这种现象进行一定的研究。同时，提出几种防止的策略。
关键词：数据库；丢失更新；防止策略
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2014）24-5593-02
Lost Update Phenomena of Research in the Database Concurrency Operations
ZHOU Wei
（Wuxi Institute of Technology， Wuxi 214121， China）
Abstract： Lost update is a classic database problem. It exists in a multi-user computer environment. As a database developer， through empathy example， to show what is lost update phenomenon， and conduct some research this phenomenon. Meanwhile， put forward several prevention strategies.
Key words： database； lost update； prevention strategies
1 概述
当2个或多个用户同时（时间上重叠）编辑同一行数据时会发生丢失更新，特别是在基于Web的应用程序中常常出现。在实际运行过程中，可能在几天甚至几个月中才会出现一次。这种现象只是随机地、零星地出现，而且在受控环境中完全不可再生，对应用程序是致命的。导致开发人员误以为是用户的错误，其实是开发人员在编写应用程序的时候，没有处理好DML命令。
2 丢失更新的现象
丢失更新是指2个或多个事务读取同一数据并进行修改，其中一个事务的修改结果破坏了另一个事务修改的结果。有两类丢失更新：
1） A事务撤销时，把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题。A事务在撤销时，“不小心”将B事务已经转入账户的金额给抹去了。
2） A事务覆盖B事务已经提交的数据，造成B事务所做操作丢失。由于转账事务覆盖了取款事务对存款余额所做的更新，导致银行最后损失了100元，相反如果转账事务先提交，那么用户账户将损失100元。
在此过程中，买家A的“取消”订单的动作，发生丢失。同时，对卖家造成了一定的经济损失。
如何防止买家A的“取消”动作不会丢失，或者卖家的“发货”动作不会丢失呢？下面提出4种策略，加以证明。
4 防止丢失更新的策略
1） 设置数据库的隔离级别为Serializable
当是查询操作的时候添加共享锁，共享锁下被人可以访问同一条记录；当进行修改操作的时候加排他锁，别人不可以修改。内在机制是异常退出机制。
卖家查询订单的时候，给这个订单记录添加了共享锁，买家可以查看。同理，买家查看他的订单的时候，也为自己的记录添加了共享锁，但共享锁下不能再添加排他锁。当卖家想做修改操作（“发货”）的时候，给这个订单记录添加一个排他锁是加不上的，他需要等，等待买家释放了共享锁，也就是提交了事务，这个排它锁才可以加上。但此时，如果买家也想操作这个订单记录，想给他的订单记录添加排他锁，也是不可以的，因为卖家那边已经有了共享锁，买家想操作的话，也必须让卖家去释放这个共享锁。这样，卖家就要等买家，买家也要等卖家。假设，此时买家做了修改的操作，根据共享锁存在的情况下，不能加排他锁的原则，买家那里就会出现异常。此时这个“取消”操作终止，“取消”操作无效。就不会产生“取消”操作的丢失。
2） 悲观锁
一种进行修改的时候，就给这条订单记录加锁，别人就不能再操作了。悲观锁就是程序员认为，客户访问某条记录的时候，很有可能其他人也在访问同条记录。保险起见，为这条订单记录加一把悲观锁，此时其他任何人都不可以修改这条记录。这种锁，适用于更新多查询少的系统。
3） 乐观锁
乐观锁就是指当买家或卖家要修改一条订单记录的时候，不认为会有别人和自己同时操作这条订单记录。可利用至少两种方式实现：
（1） 在订单表中，添加一个version字段，数据类型为identity，表示版本
在修改的的时候利用版本号机制，那么别人的操作会因为版本号的差异而失效。当第一次操作的完毕的时候，这个版本号就自动加1，此时别人如果想要修改这条记录的时候，会因为版本号的原因就不能做修改了。适用于查询多更新少的系统。
（2） 在订单表中，添加一个timestamp字段，数据类型也为timestamp时间戳（类似于邮局的邮戳）
时间戳列中存放的是一个十六进制的数据，不管是买家或卖家的任何操作，都会产生一个唯一的时间戳值。在卖家“发货”或买家“取消”订单的时候，都会检测时间戳值的值有没有发生变化。如果不变，则继续；反之，则操作不能进行。
4） 通过IF语句搭配订单状态的检查，也可防止丢失更新
（1） 假如买家想“取消”订单，操作代码如图3。
（2） 假如卖家想为订单“发货”，操作代码如图4。
图4 发货
这样，不管“取消”、“发货”两个动作发生的先后次序如何，均不会发生“取消”丢失，或“发货”丢失。
5 结束语
在数据库并发操作过程中，如果丢失更新的现象，数据库开发人员在设计的时候，就能考虑全面，那么是完全能够避免的。除
了程序控制外，还有许多工具也可以保护、避免这种情况，如Oracle Forms和HTML DB等。这些工具能确保：从查询记录的那个时刻开始，这个记录没有改变，而且对它执行任何修改时都会将其锁定。为了用户的切身利益，作为一名数据库开发者，将继续研究丢失更新的现象，寻求更多的解决办法。
参考文献：
[1]（美）刘易斯.数据库与事务处理[M]. 1版.北京：机械工业出版社，2005：537-547.
[2] 程云志.数据库原理与SQL Server 2005应用教程[M]. 1版.北京：机械工业出版社，2012：236-240.
[3] 蒋瀚洋，李月军，庞娅娟.SQL Server 2005数据库管理与开发教程[M]. 1版.北京：人民邮电出版社，2009：147-152.
[4] 陆琳，刘桂林.数据库技术与应用-SQL server 2005（应用篇）[M]. 1版.长沙：中南大学出版社，2010：290-295.
[5] 吕鹏.数据库更新丢失解决方案.IT/计算.[2011-08-10].
[6] 孟宪虎，马雪英，邓绪斌.大型数据库管理系统技术、应用与实例分析——基于SQL Server 2005[M]. 2版.北京：电子工业出版社，2011：119-137
[7] 李萍，黄可望，黄能耿.SQL Server 数据库应用及实训[M].1版.无锡职业技术学院，2014：96-102.endprint
摘要： 丢失更新（lost update）是一个经典的数据库问题，在多用户计算机环境中存在。作为一名数据库开发者，通过感同身受的例子，向大家展示何为丢失更新现象，并对这种现象进行一定的研究。同时，提出几种防止的策略。
关键词：数据库；丢失更新；防止策略
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2014）24-5593-02
Lost Update Phenomena of Research in the Database Concurrency Operations
ZHOU Wei
（Wuxi Institute of Technology， Wuxi 214121， China）
Abstract： Lost update is a classic database problem. It exists in a multi-user computer environment. As a database developer， through empathy example， to show what is lost update phenomenon， and conduct some research this phenomenon. Meanwhile， put forward several prevention strategies.
Key words： database； lost update； prevention strategies
1 概述
当2个或多个用户同时（时间上重叠）编辑同一行数据时会发生丢失更新，特别是在基于Web的应用程序中常常出现。在实际运行过程中，可能在几天甚至几个月中才会出现一次。这种现象只是随机地、零星地出现，而且在受控环境中完全不可再生，对应用程序是致命的。导致开发人员误以为是用户的错误，其实是开发人员在编写应用程序的时候，没有处理好DML命令。
2 丢失更新的现象
丢失更新是指2个或多个事务读取同一数据并进行修改，其中一个事务的修改结果破坏了另一个事务修改的结果。有两类丢失更新：
1） A事务撤销时，把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题。A事务在撤销时，“不小心”将B事务已经转入账户的金额给抹去了。
2） A事务覆盖B事务已经提交的数据，造成B事务所做操作丢失。由于转账事务覆盖了取款事务对存款余额所做的更新，导致银行最后损失了100元，相反如果转账事务先提交，那么用户账户将损失100元。
在此过程中，买家A的“取消”订单的动作，发生丢失。同时，对卖家造成了一定的经济损失。
如何防止买家A的“取消”动作不会丢失，或者卖家的“发货”动作不会丢失呢？下面提出4种策略，加以证明。
4 防止丢失更新的策略
1） 设置数据库的隔离级别为Serializable
当是查询操作的时候添加共享锁，共享锁下被人可以访问同一条记录；当进行修改操作的时候加排他锁，别人不可以修改。内在机制是异常退出机制。
卖家查询订单的时候，给这个订单记录添加了共享锁，买家可以查看。同理，买家查看他的订单的时候，也为自己的记录添加了共享锁，但共享锁下不能再添加排他锁。当卖家想做修改操作（“发货”）的时候，给这个订单记录添加一个排他锁是加不上的，他需要等，等待买家释放了共享锁，也就是提交了事务，这个排它锁才可以加上。但此时，如果买家也想操作这个订单记录，想给他的订单记录添加排他锁，也是不可以的，因为卖家那边已经有了共享锁，买家想操作的话，也必须让卖家去释放这个共享锁。这样，卖家就要等买家，买家也要等卖家。假设，此时买家做了修改的操作，根据共享锁存在的情况下，不能加排他锁的原则，买家那里就会出现异常。此时这个“取消”操作终止，“取消”操作无效。就不会产生“取消”操作的丢失。
2） 悲观锁
一种进行修改的时候，就给这条订单记录加锁，别人就不能再操作了。悲观锁就是程序员认为，客户访问某条记录的时候，很有可能其他人也在访问同条记录。保险起见，为这条订单记录加一把悲观锁，此时其他任何人都不可以修改这条记录。这种锁，适用于更新多查询少的系统。
3） 乐观锁
乐观锁就是指当买家或卖家要修改一条订单记录的时候，不认为会有别人和自己同时操作这条订单记录。可利用至少两种方式实现：
（1） 在订单表中，添加一个version字段，数据类型为identity，表示版本
在修改的的时候利用版本号机制，那么别人的操作会因为版本号的差异而失效。当第一次操作的完毕的时候，这个版本号就自动加1，此时别人如果想要修改这条记录的时候，会因为版本号的原因就不能做修改了。适用于查询多更新少的系统。
（2） 在订单表中，添加一个timestamp字段，数据类型也为timestamp时间戳（类似于邮局的邮戳）
时间戳列中存放的是一个十六进制的数据，不管是买家或卖家的任何操作，都会产生一个唯一的时间戳值。在卖家“发货”或买家“取消”订单的时候，都会检测时间戳值的值有没有发生变化。如果不变，则继续；反之，则操作不能进行。
4） 通过IF语句搭配订单状态的检查，也可防止丢失更新
（1） 假如买家想“取消”订单，操作代码如图3。
（2） 假如卖家想为订单“发货”，操作代码如图4。
图4 发货
这样，不管“取消”、“发货”两个动作发生的先后次序如何，均不会发生“取消”丢失，或“发货”丢失。
5 结束语
在数据库并发操作过程中，如果丢失更新的现象，数据库开发人员在设计的时候，就能考虑全面，那么是完全能够避免的。除
了程序控制外，还有许多工具也可以保护、避免这种情况，如Oracle Forms和HTML DB等。这些工具能确保：从查询记录的那个时刻开始，这个记录没有改变，而且对它执行任何修改时都会将其锁定。为了用户的切身利益，作为一名数据库开发者，将继续研究丢失更新的现象，寻求更多的解决办法。
参考文献：
[1]（美）刘易斯.数据库与事务处理[M]. 1版.北京：机械工业出版社，2005：537-547.
[2] 程云志.数据库原理与SQL Server 2005应用教程[M]. 1版.北京：机械工业出版社，2012：236-240.
[3] 蒋瀚洋，李月军，庞娅娟.SQL Server 2005数据库管理与开发教程[M]. 1版.北京：人民邮电出版社，2009：147-152.
[4] 陆琳，刘桂林.数据库技术与应用-SQL server 2005（应用篇）[M]. 1版.长沙：中南大学出版社，2010：290-295.
[5] 吕鹏.数据库更新丢失解决方案.IT/计算.[2011-08-10].
[6] 孟宪虎，马雪英，邓绪斌.大型数据库管理系统技术、应用与实例分析——基于SQL Server 2005[M]. 2版.北京：电子工业出版社，2011：119-137
[7] 李萍，黄可望，黄能耿.SQL Server 数据库应用及实训[M].1版.无锡职业技术学院，2014：96-102.endprint
