One is that it seems like script/runner does some caching because if
you destroy a bunch of active record models using myrec.destroy, then
if you do a find() of some sort, they are still there (even though you
deleted them) until the instance of script runner that you are in
exits. Then if you restart it, the find will not find it.
Based on that, it seems that it might be better to have a long
running process spawn script/runner jobs separately rather than have a
script/runner that runs for a long time and does a ton of stuff, not
sure on that ?
I also noticed that backgroundrb logs to the same log as the web
server. If a whole ton of stuff happens in backgroundrb, could this
potentially slow down the web server because it uses the same log
file ? The same question applies for script/runner. I see it happening
more so because I run the server from the console while developing
probably etc.
One is that it seems like script/runner does some caching because if
you destroy a bunch of active record models using myrec.destroy, then
if you do a find() of some sort, they are still there (even though you
deleted them) until the instance of script runner that you are in
exits. Then if you restart it, the find will not find it.
Based on that, it seems that it might be better to have a long
running process spawn script/runner jobs separately rather than have a
script/runner that runs for a long time and does a ton of stuff, not
sure on that ?
I also noticed that backgroundrb logs to the same log as the web
server. If a whole ton of stuff happens in backgroundrb, could this
potentially slow down the web server because it uses the same log
file ? The same question applies for script/runner. I see it happening
more so because I run the server from the console while developing
probably etc.
You might try
YourARModel.clear_query_cache
if you feel caching is to blame for returning stale (already deleted) rows. However, I am skeptical that caching is the problem, as it (AFAICT) caches the most recent query so you have to make a query identical to the last one for it to kick in. Additionally, any modification to the model such as creating, updating, or deleting should invalidate that cache.
You might try to reproduce this in a simple test case and look at the SQL in your logs to make sure you are seeing what you expect.
