关于数据库并发处理数据的问题

现在有这样一个问题。有一个商品信息表，包含了商品价格。假设现在有两个部门：财务部门 A 和 销售部门 B，都有权利去修改商品的价格。现在A查询一个产品X,价格为200。 B也查询了X的价格。现在A修改了这个价格X=300.此价格为商品正确价格。但是B部门此时不知道X的当前价格。而B部门也修改X的价格=250。此时价格就出现了问题。
 请问这样的情况要如何去处理。本人看了数据库相关的一些锁的内容。悲观锁和乐观锁感觉都解决不了。貌似不是同一问题。 请高人解答！

没有这么巧的时候吧....
如果当时价格不是看的价格的话@@rowcount就等于0了
而且出现这种问题好像问题也不是很大.如果有必要的话这样写

就是碰到了这样的问题。。 
目前的处理是在更新数据前 读取内存里的值，如果不相等就阻止更新。你那个sql语句没用啊

加个字段，，，记录当前读取记录的用户名与读取时间，，，作为判定当前行数据是否被其他人读取
被读取则阻止其他人的读取，，，
退出后update那个标记字段为空，，若15分钟不退出，自动清空

锁是拿来处理普通的并发，，，你这个是业务上的特殊的并发处理- -
自然特殊对待应该加锁，当A修改价格时，应该锁住B不能修改。

那请问如何设置 定时处理 更新？用SqlServer的Job 自动来Run? 那如何设置它的开始时间？

额，问题可能我没描述清楚。。 A修改完成 提交事务之后 B再去修改

目前是A修改完了 退出之后。B再去修改。 就像4楼说的并不是普通的锁能解决的

初始状态：
商品价格=200 A读取，B读取
  A修改价格=300，退出事务
  B修改价格=250，退出事务

可以考虑一下3F的方式。

在这类系统中是会出现这样的问题，通常是在应用中结合权限方式考虑，比如根据资料的类型只允许哪些部分修改A类资料等。
13F的情况在事实中是存在的。

此时B处于等待队列，数据会被最终完成事务方所修改跟数据库的并发没关系,貌似没有好的解决方式.

感觉这是业务逻辑的问题，并不跟数据库锁有任何关系。A部门看到价格后想改成300，B部门看到价格后想改成250，就算B知道A改成了300那又怎么样？他还是要去改成250。至于你说的B不知道A改过价格，你可以在A改完价格后给出提示啊，B是在A改完后才去改的，那B就会看到这个消息啊。

16 17楼理解的正确
就是这种情况目前的解决方案是 目前的处理是在更新数据前 读取内存里的值与数据库中当前值比较，如果不相等就阻止更新。
不知是否还有好的方案

--不知我的理解对不对。。。。
此时就产生了冲突A,B相互之间不知道彼此都对这个价格修改过
来源：nba直播