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? Thanks, Greg Campbell
_______________________________________________ Backgroundrb-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/backgroundrb-devel
