这样的处理合不合理？？
0
悬赏园豆：10
[待解决问题]
最近项目上遇到这样一个需求。。
类似于淘宝的订货系统，用户点击提交订单，后台做如下处理：
spring框架，Service
1. 生成订单 Order order = new Order(); orderDao.insert(order);
2. 生成付款单 Pay pay = new pay(); payDao.insert(pay);
3 主要是第三步 库存减少相应的数量，如果减完数量小于0，上述操作回滚。
以下是个人的解决方法：
1 在Service方法上加入@Transactional 标签
2 自定义一个异常类 new InventoryShortExeption();
3 when (库存减少后的数量<0){ throw new InventoryShortExeption(库存不足);}
这样主要是用到了@Transactional 标签的异常回滚机制，想问问大家做类似的业务需求时是怎样处理的，我这样的处理是否合理？
所有回答(3)
0
我觉得在生成订单时就先判断一下库存，库存小于订单数量，就给用户提示
0
事务范围太大了吧，你前面插入订单和支付订单这个没必要放到事务里的。这些信息在库存不够的情况下保留在db中也很正常的。
如果你非要保证订单存在必须会扣减库存的话，也应该是前面做库存的预减，如果多长时间内没有被支付等再还原。
0
用户量大的话还是建议使用消息队列处理，用户体验好，用户下完订单后不需要等待后台响应而是将生成的订单存入第三方消息队列中后，从队列系系统直接回馈订单下单成功了，队列会按顺序再去访问库存系统做相应的处理。疑问？：你们项目上产品对应的库存不会在UI展示给用户吗？可以直接在客户端直接控制用户下单的数量啊！根本就不让这个订单去访问库存系统了，怎么会出现减完数量小于0的情况？
这个也和上面反应过，现在是提交订单是在”购物车”中提交订单，加入购物车的时候有对库存控制，但在购物车生成订单的时候，有可能出现库存不足和商品下架的情况，淘宝的处理方式是直接把下架或者库存不足的商品直接从购物车中移除，我们的项目并没有在加载购物车的时候筛选商品，所以提交订单的时候会出现库存不足和下架的情况，使的提交订单变得异常复杂。
第三方消息队列也没有引入，因为项目也是第一次上线，甚至现在也还是处于测试阶段，并没有真正的上线运营。
抛异常来达到事务回滚是我这种新手没有办法想到的方法。
理想的思路应该是这样你看对不对：
1.加载购物时把库存不足或者下架的商品移除或者变灰不允许操作。
2.提交订单是使用队列，加入判断是不是可以避免抢单的情况？还用加锁来避免抢单吗？
