MySQL MYISAM 两个进程的并发问题
我可能忽略了一些简单的事情，但几周来我一直在试图了解这里出了什么问题，我需要一双新的眼睛。
我有一个处理 Paypal 付款通知的 CGI 应用程序。 当有人订阅时，我实际上会获得一个订阅 IPN，然后是一个付款 IPN。 On 就在另一个进程的后面，因此我启动了两个 CGI 进程。 我为每个日志创建一个单独的日志，并且时间戳是相同的（与时间戳的分辨率 - 秒）。
CGii 应用程序旨在为新订户创建用户帐户，然后支付 IPN 将信息添加到新创建的帐户中。 够简单的。
问题是第二个 IPN 无法找到该帐户。 我认为这是因为在第二个 IPN 寻找它时它已经完成创建，所以我将第二个 IPN 延迟了 5 秒。
现在，时间戳显示为第一个 IPN 创建帐户的函数已在第二个 IPN 开始查找之前返回，这意味着 INSERT 在发出第一个 SELECT 之前已完成。 没有运气。
我想知道是否是缓存问题： http://dev.mysql.com/tech-resources/文章/mysql-query-cache.html 但我不这么认为。
我在这里根本没有使用 TRANSACTIONS，但在第二个 CGI 应用程序发出 SELECT 之前我还没有释放第一个 CGI 应用程序的句柄，但这应该不重要。 我想我可以尝试发出“我可能忽略了一些简单的事情”，但几周来我一直在试图了解这里出了什么问题，我需要一双新的眼睛。
我有一个处理 Paypal 付款通知的 CGI 应用程序。 当有人订阅时，我实际上会获得一个订阅 IPN，然后是一个付款 IPN。 On 就在另一个进程的后面，因此我启动了两个 CGI 进程。 我为每个日志创建一个单独的日志，并且时间戳是相同的（与时间戳的分辨率 - 秒）。
CGii 应用程序旨在为新订户创建用户帐户，然后付款 IPN 将信息添加到新创建的帐户中。 够简单的。
问题是第二个 IPN 无法找到该帐户。 我认为这是因为在第二个 IPN 寻找它时它已经创建完成，所以我将第二个 IPN 延迟了 5 秒。
现在，时间戳显示为第一个 IPN 创建帐户的函数在第二个 IPN 开始查找之前已返回，这意味着 INSERT 在发出第一个 SELECT 之前已完成。 没有运气。
我想知道是否是缓存问题： http://dev.mysql.com/tech-resources/文章/mysql-query-cache.html 但我不这么认为。
我没有使用 TRANSACTIONS，但我没有尝试在 INSERT 之后发出 COMMIT。
我在这里缺少什么？
I have probably overlooked something simple, but I have been trying to understand what is going wrong here for a few weeks and I need a fresh set of eyes.
I have a CGI application that processes Paypal Payment notifications. When someone subscribes I actually get a subscription IPN followed by a payment IPN. On is right behind the other so I two CGI processes are launched. I create a seperate log for each one and teh time stamps are identical (to the resolution of the timestamp - seconds).
The CGii application is designed to create a user account for a new subscriber and then the payment IPN adds information to the newly created account. Simple enough.
The problem is that the second IPN is not able to find the account. I assumed this is because it had finished being created at the time the second IPN went looking for it, so I delayed the second IPN by 5 seconds.
Now the timestamps show that the function that creates the account for the first IPN have returned before the second IPN begins looking for it, meaning the INSERT is complete before the first SELECT is issued. No luck.
I wondered if it was caching issue:
http://dev.mysql.com/tech-resources/articles/mysql-query-cache.html
But I dont think so.
I am not using TRANSACTIONS at all here, but I have not releaase the handle for the first CGI application before the second issues its SELECT, but this should not matter. I guess I could try issuing a I have probably overlooked something simple, but I have been trying to understand what is going wrong here for a few weeks and I need a fresh set of eyes.
I have a CGI application that processes Paypal Payment notifications. When someone subscribes I actually get a subscription IPN followed by a payment IPN. On is right behind the other so I two CGI processes are launched. I create a seperate log for each one and teh time stamps are identical (to the resolution of the timestamp - seconds).
The CGii application is designed to create a user account for a new subscriber and then the payment IPN adds information to the newly created account. Simple enough.
The problem is that the second IPN is not able to find the account. I assumed this is because it had finished being created at the time the second IPN went looking for it, so I delayed the second IPN by 5 seconds.
Now the timestamps show that the function that creates the account for the first IPN have returned before the second IPN begins looking for it, meaning the INSERT is complete before the first SELECT is issued. No luck.
I wondered if it was caching issue:
http://dev.mysql.com/tech-resources/articles/mysql-query-cache.html
But I dont think so.
I am not using TRANSACTIONS, but I have not tried issuing a COMMIT after the INSERT.
What am I missing here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
MYISAM 表不支持事务，因此不会有问题。 没有任何代码可供查看，老实说，在我看来，您的第二个查询使用了错误的 id。 除了时间戳之外，您还记录什么？ 我会记录整个查询并确保 id 相对应，并且第二个查询正在查找正确的记录。 也许尝试仅使用 SQL 手动重现该情况，并在测试查询时将脚本排除在外。
MYISAM tables don't support transactions, so it won't be a problem there. Without any code to look at, it honestly sounds to me like your second query is using the wrong id. What are you logging besides the timestamps? I'd log the entire queries and make sure the ids correspond and that the second query is looking for the right record. Perhaps try to reproduce the situation manually using only SQL, and leave the scripts out of it while you test your queries.