[Backgroundrb-devel] Registering status for multithreaded worker?
gethemant at gmail.com
Thu Feb 21 06:54:53 EST 2008
On Thu, Feb 21, 2008 at 6:33 AM, Greg Campbell <gtcampbell at gmail.com> wrote:
> Hi all,
> I'm using a backgroundrb worker for processing data reporting tasks which
> can be initiated by users of my rails application, and which need to support
> status monitoring. I had been spawning a new instance with a new job_id for
> each task, and reporting/requesting status via that job_id. It appears that
> this sort of thing may be better handled by thread_pool, but there seem to
> be two ways of dealing with status reporting, and I'm curious whether people
> have found one to be preferable over the other:
> I could track status in the database, as I'm creating a new row for each
> task anyway to store the results, or I could use register_status, with a
> hash keyed on the equivalent of job_id (inside a mutex, as suggested in the
> README). Is there any reason to prefer the second over the first?
> Alternately, am I incorrect in assuming that thread_pool is preferable to
> spawning one worker per user request?
thread_pool is definitely preferable over one worker per request approach.
Also, usually register_status is faster than your hand rolled approach
of using databases. Also, if worker status results can be stored in
memcache clusters as well hence is preferable.
More information about the Backgroundrb-devel