Hi Greg, On Thu, Feb 21, 2008 at 6:33 AM, Greg Campbell <[EMAIL PROTECTED]> 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. _______________________________________________ Backgroundrb-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/backgroundrb-devel
