如题,利用asp.net的application怎么处理同时购物的线程;比如当商品库存只有一件时,怎么处理有两个用户同时购买这个商品?好像是用加锁解锁,但不知道怎么用,或者有更好的方法吗????

解决方案 »

  1.   

    一般这类需求都是靠数据库的事务校验。如果想用户体验,前台先进行 ajax校验,但是后台校验是必须的。
      

  2.   

    通过设置事务的隔离级别标准SQL规范中,定义了4个事务隔离级别,不同的隔离级别对事务的处理不同:
     
      ◆未授权读取(Read Uncommitted):允许脏读取,但不允许更新丢失。如果一个事务已经开始写数据,则另外一个数据则不允许同时进行写操作,但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。
     
      ◆授权读取(Read Committed):允许不可重复读取,但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据,但是未提交的写事务将会禁止其他事务访问该行。
     
      ◆可重复读取(Repeatable Read):禁止不可重复读取和脏读取,但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务(但允许读事务),写事务则禁止任何其他事务。
     
      ◆序列化(Serializable):提供严格的事务隔离。它要求事务序列化执行,事务只能一个接着一个地执行,但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的,必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。
     
      隔离级别越高,越能保证数据的完整性和一致性,但是对并发性能的影响也越大。对于多数应用程序,可以优先考虑把数据库系统的隔离级别设为 Read Committed,它能够避免脏读取,而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题,在可能出现这类问题的个别场合,可以由应用程序采用悲观锁或乐观锁来控制。参考这个链接 http://blog.csdn.net/wxzyq/article/details/6965283
      

  3.   

    这是没有问题的啊,先用cookes记录商品ID,但他要购买的时候,再根据ID读取商品,然后处理数据,写入数据库,这样就不存在并发的情况了
      

  4.   

    前台校验库存是否足够,不足够提示库存不足(如果你的业务定义为不可负出库),提交的时候 查找库存事务开始
    select 产品ID from 库存表 where 产品ID=/页面传递/ 为这条数据加锁(加锁的代码根据你使用不同的数据库或者不同的orm产品,编写相应的代码,有的产品只要在事务中执行了查询语句就自动锁表)update 库存表 where 数量=数量-/页面传递数量/ 如果你业务定义不允许负出库( 数量-/页面传递数量/>0)
    如果不满足条件,影响行数==0 抛出异常update 配送表 .....以及其他业务表事务提交
    个人感觉虽然这个业务不复杂,但是针对写代码的经验还是有一定要求的,如果楼主不是十分明白,可以把这个需求给有经验的工程师编写。