有许多与我的问题相关的类似问题。但是我没有找到满意的答案。所以我将这个问题放在这个论坛中。
我对库存管理系统中的并发控制有疑问。说我有数量为2、3、4的产品A，B，C。我的应用程序是多用户。
我有产品页面，用户可以在其中查看产品列表和可用数量。并且我有结帐页面和付款页面，可能需要一些时间才能到达产品页面。
现在，如果它是多用户Web应用程序，并且说用户1已订购2个数量的产品A，但尚未下订单，则用户2仍然可以看到2个数量的A。
我应该暂时（可配置的时间）锁定2件产品A，直到下订单吗？这是一个好的设计。如果是，我应该锁定Java还是数据库？
不，这不是一个好的设计，因为它很容易引起滥用和问题。如果用户（竞争对手？）在整个月内锁定了您所有的产品怎么办？如果另一个人用产品填满了他/她的购物车，然后又确定它花了太多钱而只是关闭了他/她的设备怎么办？
最佳选择是：
1]告诉用户每种产品的可用性如何，还告诉他/她如果不尽快下订单，它可能会消失。这也应该刺激销售。在付款页面后（即有业务承诺要进行操作时），请锁定/解锁产品。如果可用数量不再足够，请将用户发送回上一页，将数量更新为更多。
2）与1）类似，但是您也可以不时更新可用性。或发送警告，例如“购物车中某些物品的库存不足”。同样，这也可以促进销售。
3）在将物品移至购物车时保留（“锁定”）物品，但不能永久保存。锁定一段时间后释放物品。随时通知用户。超时可以针对整个购物车或每个商品。
注意到上述任何“锁定”都是“业务锁定/保留”，这一点非常重要。不需要以锁或任何其他特定技术解决方案的形式实现。例如，可以通过添加字段locked_by和locked_until来实现上述3）。在检查/更新/操作这些字段时，您可能需要在“技术锁”内进行操作。检查/更新完成后，将解除技术锁定。但是，由于locked_until尚未过去，因此“商务锁”仍然可以使用，并且任何其他代码都将检查此字段以考虑该产品是否可用。为什么？因为业务规则是强制性的（不是因为存在技术锁定，实际上不是这样）。
“技术锁”应该很快。 “商务锁”可以更长（但永远不会永远；总是为它们定义时间限制）。
很难告诉您是否应该仅用很少的信息将“ Java”锁定在“数据库中”。例如，您在使用实体Bean吗？您的容错要求是什么？等
也就是说，在一般情况下，将锁（只要它们是“业务锁”）最好保留在数据库中，原因如下：
我应该暂时（可配置的时间）锁定2件产品A，直到下订单吗？这是一个好的设计。
这取决于您网站的会话率，即结帐次数/付款次数。如果您的会话率很高，则可以预先锁定数量，以获得更好的用户体验。
如果是，我应该锁定Java还是锁定数据库？
您需要全局锁以确保正确性。如果您有多个应用程序服务器，则必须将锁放入数据库中。
库存管理应由重新构建的自定义系统处理。出于性能原因，您不能仅依赖ACID合规性。在订单期间在库存上实施交易是一个非常糟糕的主意，并且不能扩展。我提出以下解决方案。