Rails批处理问题
在我的应用程序中,用户可以将帖子的状态设置为不同的标志,例如“v”-可见,“d”-删除标记等。
这些标志是通过控制器操作设置的。
我有一个批处理进程,可以运行并清理所有标记为删除的帖子。
Post.find(:all, :conditions => ['status = ?', 'd']).each do |p| p.销毁 一次
此批处理过程每 x 分钟运行
。假设用户用 'd' => 标记帖子批处理在某些点运行=>当进程运行时,用户将帖子标记为“v”。现在,在批处理过程中,记录已经成为删除目标,并且将在 do 循环完成时进行,但标志已通过控制器操作更改。
理想情况下,如果发生这种情况,我不想在批处理过程中删除该帖子。
处理这个问题的最佳方法是什么?
In my app a user can set the status of a Post to different flags like 'v' - visible, 'd' - mark for delete etc.
These flags are set via controller actions.
I have a batch process that runs and cleans all the posts marked for delete.
Post.find(:all, :conditions => ['status = ?', 'd']).each do |p|
p.destroy
end
This batch process runs every x many minutes.
Let's say a user marks the post with 'd' => batch process runs at some points => while the process is running the user marks the post as 'v'. Now inside the batch process the record is already targeted for delete and will be when the do loop is done, but the flag has changed via the controller action.
Ideally, if this happens I would like to not delete that post in the batch process.
What's the best way to handle this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
按照您的描述,存在竞争条件。 -- 当帖子已经处于删除过程中时,用户可以标记帖子 v。并且用户的请求将被忽略。
根据您的目标,有很多方法可以更改此设置:
1)更改
此设置将最大限度地缩短检查状态和删除帖子之间的时间窗口。
2) 将帖子的显示更改为仅在状态不是“d”时显示帖子。这将有效地加快删除速度,因为其他人将有更少的时间将要删除的帖子标记为“v”
3)为了给人们更长的时间来改变主意,每天只运行一次批处理作业,晚点夜晚。一旦帖子被标记为d(待删除),就会以特殊的方式显示该帖子,以警告用户该帖子即将被删除。这给了他们最大的时间来撤消删除请求。
4) 切勿真正销毁数据。 (DBMS 存储很便宜。)当帖子被标记为删除时,只需更改标志即可不再显示它。这使得用户可以随时“取消删除”帖子——无需担心截止日期,也无需担心任何竞争条件。
The way you described it, there is a race condition. -- The user can mark the post v when it is already in the process of being deleted. And the user's request will be ignored.
Lots of ways to change this depending on your goals:
1) Change from
This will minimize the window of time between the status being checked and the post deleted.
2) Change the display of the posts to only show the posts if the status is not "d." This will effectively speedup the deletion since others will have much less time to mark a to-be-deleted post as "v"
3) To give people a longer period to change their minds, only run the batch job once a day, late at night. Once a post is marked as d (to-be-deleted), show the post in a special way to warn users that the post is about to be deleted. This gives them max time to undo the delete request.
4) Never actually destroy the data. (DBMS storage is cheap.) When a post is marked for deletion, just change a flag and don't show it again. This enables users to "undelete" the post whenever they want to--no deadlines to worry about, nor any race conditions.