1

私のアプリでは、ユーザーは投稿のステータスを「v」-表示、「d」-削除のマークなどのさまざまなフラグに設定できます。

これらのフラグは、コントローラーアクションを介して設定されます。

削除のマークが付けられたすべての投稿を実行してクリーンアップするバッチプロセスがあります。

Post.find（：all、：conditions => ['status =？'、'd']）。each do | p | p.destroy終了

このバッチプロセスは、x分ごとに実行されます。

ユーザーが投稿に「d」のマークを付けたとします=>プロセスの実行中にバッチプロセスがいくつかのポイントで実行されます=>ユーザーが投稿に「v」のマークを付けます。これで、バッチプロセス内で、レコードはすでに削除の対象になり、doループが実行されたときになりますが、フラグはコントローラーアクションによって変更されました。

理想的には、これが発生した場合、バッチプロセスでその投稿を削除したくありません。

これを処理するための最良の方法は何ですか？

4

1 に答える 1

2

あなたがそれを説明したように、競合状態があります。-投稿がすでに削除されている場合、ユーザーは投稿にマークを付けることができます。そして、ユーザーの要求は無視されます。

目標に応じてこれを変更する方法はたくさんあります。

1）から変更

Post.find(:all, :conditions => ['status = ?', 'd']).each do |p| p.destroy end
to
Post.find(:all, :conditions => ['status = ?', 'd']).each do |p|
   p.reload
   p.destroy if p.status == 'd' 
end

これにより、ステータスがチェックされてから投稿が削除されるまでの時間が最小限に抑えられます。

2）投稿の表示を変更して、ステータスが「d」でない場合にのみ投稿を表示するようにします。他の人が削除される投稿を「v」としてマークする時間がはるかに少なくなるので、これは効果的に削除をスピードアップします

3）人々が考えを変えるためのより長い期間を与えるために、バッチジョブを1日1回、深夜にのみ実行します。投稿にd（削除予定）のマークが付けられたら、特別な方法で投稿を表示して、投稿が削除されようとしていることをユーザーに警告します。これにより、削除リクエストを元に戻すための最大時間が与えられます。

4）実際にデータを破棄しないでください。（DBMSストレージは安価です。）投稿に削除のマークが付けられたら、フラグを変更するだけで、再度表示しないでください。これにより、ユーザーはいつでも投稿を「元に戻す」ことができます。締め切りや競合状態について心配する必要はありません。

于 2010-09-06T03:10:36.283 に答える