事务并发问题一直想不到好的解决方法,请帮忙
一个进销存系统,基本所有的业务都要操作库存表,增加总库存或者是减少总库存,请问当多个用户同时并发操作时,怎样保证总库存数据的正确性呢?
我自己有想到一种方法:就是在库存表增加一字段如:是否锁,当需要改变库存这个字段时,首先取出库存字段和是否锁字段,如果是否锁字段=Y 那么说明已经有人占用,提示用户等待,否则取出库存交更新是否锁字段为Y,说明已经占用,当更新完库存后再UPDATE 是否占用=N,
不知道有没其它更好的方法,或者对于事务并发我的理解错在哪?
谢谢!

解决方案 »

  1.   

    锁不好,设置存量的check约束为>=0,用Update存量=存量-用量的方式去减存量,如果有存量的限制的话,把存量的拆分成可用存量和最低存量两个字段,做为商家,最忌讳的是卖不出东西,而不是客户买不到东西.
      

  2.   

    当你说“锁”的时候,我的第一感觉似乎你制作过FoxBase子类的。因为即使Access这样的文件服务器式的单机多用户数据库,也是支持事务的。数据库技术中,事务是一个重要的技术。锁既不是一个表机的概念,也不是一个逻辑的概念,它既不低俗(表锁)也不过高(业务逻辑中去考虑),它是很基本的。你可以看看你的事据库系统中有关“事务”的概念即可。
      

  3.   

    数据库技术有几个方面应该熟悉来龙去脉,分为:记录与磁盘块的关系、SQL、B+树索引、事务、分布式系统。
      

  4.   


    上面几位朋友说的我不是很清楚,关于事务并发,我查过这方面资料,DMBS允许多个事务同时操作表,这就是并发,事务并发会引起后一个用户会覆盖前一用户的值或者造成数据不完整。这就是我理解的关于事务并发方面的一点知识。通常解决事务并发的方法的加锁,但是锁会带来死锁,而且性能也很不好。yuzhantao(和女朋友一起去养狗) 的思路我很赞同很可行.用时间戳标记当做版本号,当更新库存时发现时间戳不对则提示用户刷新并退出,让他重新提交更新。
      

  5.   

    DBMS中有悲观检查, 也可以用SQL关键字transact来标记事务, 如果做就都做, 如果发生故障就undo. 对于这个问题, 我觉得锁其实不错, 不会带来死锁问题吧, 因为不存在"等待环路". 只能排队, 否则有可能会读到"脏数据", 用户界面上下一些功夫, 让顾客感觉好一些, 只能这样吧. 期待更好的办法.如果供应链特别好的话, 其实还可以透支一些来提高性能, 不过这样有些不可靠.
      

  6.   

    数据库有自己的锁机制,这个机制会自动阻止所谓的“并发”修改,而且,这个机制不是你自己加一个字段就能达到的,因为,你访问这个字段的操作并不能保证“不并发”,所以,还是设计好你的更新语句,并发的事情,放心交给数据库管理系统自己去吧!
    俺同意jontan的意见
      

  7.   

    sql无需记录锁的自我规定,他自己已经处理了。
      

  8.   

    1.我发觉很多人对并发看得太简单了,系统自动处理得了吗?
    例:
    a与b用户先后打开c记录,b用户后发先至对c作了保存10值,而a随后保存20值,那a还是b所保存的值才是有效业务逻辑呢?后者保存时要么通知被锁,要么无法有效通知前者更改了新数值(因为a也许已结束当前事务并作其他去了!)这将导至业务逻辑出错.更何况存在更多人用户的并发操作可能,总不能给1人通过了,而99人看到一个"记录已被锁定了"的提示,这将严重使工作不流畅;
      

  9.   

    就使用sqlserver的锁和事务就可以了。
    进销存软件的并发事务的概率并不高。