Half baked "backgrounder" idea

At present I'm working on a couple of different Rails projects, each of which has to have background tasks running for a variety of reasons (handling large imported files, sending reminder emails at predetermined times, handling incoming emails, etc.)

So far I've been using the "spawn" plugin for this in preference to the many other equally undocumented choices mostly because it was the first one I tried that just "worked", and it is getting the job done well enough. Biggest problem is just remembering to restart the silly thing whenever the Rails app is restarted for a deployment or whatever.

Today while researching a new feature to add, I stumbled upon a different idea and I wanted to get some feedback from the community on the pro's and cons of doing "background tasks" in this way:

Why not just write a second little Rails app that doesn't happen to have any end-user facing UI? This app would use RESTful stuff for handling lengthy tasks such as handling large import files and such.

A third app would be a mindless loop, continually checking various things to see if it needs to do something like send a reminder email or handle incoming emails.

To be sure, this approach would suck up some RAM, but it would make splitting up the app when the user base gets huge an almost trivial proposition.

If one were to serve these three apps (the mail app plus two different types of background app) via "mod_rails" (Phusion Passenger), would they effectively all be in separate threads and avoid holding each other up?

Are there any hidden gotcha's involved with having three such apps connected to the same MySQL database?

P.S. I can't exactly put into words why this method appeals to me over the current method of spawning a simple background process that is more closely coupled to the main Rails app. It just seems like an interesting way to do it. Wondered what others think of it.

thanks, jp

Have a look at backgroundrb. http://backgroundrb.rubyforge.org/