私は単純なことを見落としている可能性がありますが、ここ数週間、ここで何がうまくいかないのかを理解しようとしてきたので、新鮮な目が必要です.
Paypal 支払い通知を処理する CGI アプリケーションがあります。誰かがサブスクライブすると、実際にサブスクリプション IPN とそれに続く支払い IPN を取得します。On はもう一方のすぐ後ろにあるので、2 つの CGI プロセスが起動されます。それぞれに個別のログを作成し、タイムスタンプは同じです (タイムスタンプの解像度 - 秒)。
CGii アプリケーションは、新しいサブスクライバーのユーザー アカウントを作成するように設計されており、支払い IPN が新しく作成されたアカウントに情報を追加します。十分に単純です。
問題は、2 番目の IPN がアカウントを見つけられないことです。これは、2 番目の IPN が探しに行った時点で作成が完了しているためだと思い、2 番目の IPN を 5 秒遅らせました。
タイムスタンプは、最初の IPN のアカウントを作成する関数が、2 番目の IPN が検索を開始する前に返されたことを示しています。つまり、最初の SELECT が発行される前に INSERT が完了しています。運がない。
キャッシュの問題かどうか疑問に思いました: http://dev.mysql.com/tech-resources/articles/mysql-query-cache.html しかし、そうは思いません。
ここでは TRANSACTIONS をまったく使用していませんが、2 番目の CGI アプリケーションが SELECT を発行する前に、最初の CGI アプリケーションのハンドルを解放していませんが、これは問題ではありません。おそらく単純なことを見落としている可能性がありますが、ここ数週間、ここで何がうまくいかないのかを理解しようとしており、新鮮な目が必要です。
Paypal 支払い通知を処理する CGI アプリケーションがあります。誰かがサブスクライブすると、実際にサブスクリプション IPN とそれに続く支払い IPN を取得します。On はもう一方のすぐ後ろにあるので、2 つの CGI プロセスが起動されます。それぞれに個別のログを作成し、タイムスタンプは同じです (タイムスタンプの解像度 - 秒)。
CGii アプリケーションは、新しいサブスクライバーのユーザー アカウントを作成するように設計されており、支払い IPN が新しく作成されたアカウントに情報を追加します。十分に単純です。
問題は、2 番目の IPN がアカウントを見つけられないことです。これは、2 番目の IPN が探しに行った時点で作成が完了しているためだと思い、2 番目の IPN を 5 秒遅らせました。
タイムスタンプは、最初の IPN のアカウントを作成する関数が、2 番目の IPN が検索を開始する前に返されたことを示しています。つまり、最初の SELECT が発行される前に INSERT が完了しています。運がない。
キャッシュの問題かどうか疑問に思いました: http://dev.mysql.com/tech-resources/articles/mysql-query-cache.html しかし、そうは思いません。
私は TRANSACTIONS を使用していませんが、INSERT の後に COMMIT を発行しようとはしていません。
ここで何が欠けていますか？