可以选择...进行更新，进行电子商务交易，然后在 PHP 中调用 MySQL 存储过程吗？
我目前正在为我的客户构建一个 PHP 电子商务网站。一切进展顺利，但我遇到了障碍，想知道是否有 MySQL/PHP 专家可以帮助我。基本上，电子商务网站只销售一次产品（这意味着每件商品只有一个库存数量），这意味着一旦客户结帐该商品就无法再购买。
因此，在结帐时，我必须检查该产品是否仍有库存。假设这是一个流量很大的网站，可能会出现两个或更多客户尝试同时结账的情况，因此两人都能够购买该产品。因此，为了防止这种情况，我的计划如下：
- 在产品上选择...FOR UPDATE，以锁定表行。
- 做电商交易（Paypal、authorize.net等）
- 如果电商交易成功，调用一个MySQL存储过程（其中也有SQL事务）来存储订单信息等。如果失败则ROLLBACK是否
可以实现这个计划？要执行 SELECT...FOR UPDATE，我必须启动一个 SQL 事务，但随后我还在 MySQL 存储过程中的步骤 3 中启动另一个事务。我不确定会发生什么。另外，这个计划会导致僵局吗？
很抱歉问了这么长的问题，但非常感谢您的帮助！
I am currently building a PHP e-commerce website for my client. Its been going smoothly but I've hit a roadblock and was wondering if any MySQL/PHP experts can help me. Basically, the e-commerce site sells a product only once (meaning they only have one quantity in stock for each item), which means that once a customer checks out with that item it cannot be bought anymore.
So on checkout, I have to check to see if the product is still in stock. Assuming this will be a site with heavy traffic, there could be instances where two or more customers would try to checkout at the same time, thus both would be able to buy the product. So to prevent that, my plan is as follows:
- Select...FOR UPDATE on the product, to lock the table row.
- Do e-commerce transaction (Paypal, authorize.net, etc.)
- If e-commerce transaction is successful, call a MySQL stored procedure (which also has a SQL transaction) to store order information, etc. OR ROLLBACK if failed
Is it possible to realize this plan? To perform the SELECT...FOR UPDATE, I would have to start a SQL transaction, but then I am also starting another one in Step 3 within the MySQL stored procedure. I am not sure what would happen. Also, would this plan lead to a deadlock scenario?
Sorry for the long question, but any help is appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我建议您的存储过程不应在其中包含事务控制。这似乎就是你遇到困难的原因。
如果其他调用者需要这样的存储过程，请考虑将“工作”分解为新的存储过程。
I'd suggest your stored procedure ought not to have transaction control inside it. That seems to be the cause of your difficulty.
If other callers require the stored procedure like that, consider factoring out the 'works' to a new stored procedure.