こんにちは。

セール開催などでアクセス・注文が一時的に集中する大規模サイトにおいて、在庫に関する排他制御の実装を予定しております。

過去ログやソースを追ったところでは、
「LC_Page_Shopping_Complete.php -> lfReduceStock」にて
排他モードにて行ロック（SELECT .. FROM .. FOR UPDATE）を行えば実現できるのではないかと考え、
簡単な実施テストを行い、在庫数の排他制御が想定通りとなることを確認しました。

しかしながら、
これまで正式版やコミュニティ版にて在庫に関する排他制御がなされていない点、
システムとしては比較的致命的とも言える在庫処理なのにも関わらず情報が薄い点、
など、「lfReduceStock」での行ロックの実装において、懸念事項や問題点などが存在するのか気になっております。

何か情報をお持ちの方や有識者の方々からのご意見をいただければ有難く思います。

宜しくお願いします。

−−−−−−−−−−−−−−−−
EC-CUBE：2.4.4
PHP：5.2.9
DB：MySQL 5.0.51（InnoDB）
−−−−−−−−−−−−−−−−

こんにちは。

私は同様の処理を検討した事があります。
行ロックで対応すると処理遅延等の問題が発生する可能性があります。

どこを妥協するかによりますが、決済処理の開始から終了まで排他するのが正しいと思われます。

その際にクレジット決済等、処理に時間がかかる物や処理にエラー（システムエラーやオーソリ等のエラー）が発生する場合があります。
その時に在庫の引き当ては行わない様にしなければならず、全ての処理が終わるまでロック状態にする必要がありますが、それをしてしまうと同一商品に購入のアクセスが集中してしまった場合、サーバーダウンなどトラブルになる可能性がありそうなきがします。

hatarakuweさんの中にアクセスの集中する大規模サイトとありましたがその辺は問題ないのでしょうか？
私は、この様な事をクリアする方法が見つからないので現在は検討中のままです。

こんにちは

まったく同じ処理を作成し、運営もしています。

大規模なサイトでアクセスが集中した場合に決済完了済みなのに在庫がなくてエラーになるなども起きるのでそのあたりを考慮したつくりは必要になるかと思います。

hatake様、red様

貴重なご意見をいただきありがとうございました。

今回は、同一商品へのアクセス集中時には購入制限機能を実装することで、サーバー過負荷やユーザー毎のレスポンス遅延への対応を行うこととなりました。

お忙しいなかご返信いただきましてありがとうございました。