[Backgroundrb-devel] Behaviour of pool_size setting
masonhale at gmail.com
Thu Jul 26 15:24:25 EDT 2007
> How about using the result hash as way to push information from the "queue
> managing" worker to other workers? Has anyone tried something like this?
> Is it reliable? Or are there race conditions in with the queue-managing
> worker writing to the hash and the other workers reading from their key?
I highly suggest avoiding use of the result hash. The current
implementation suffers from some threading/locking issues that result
in very weird behavior when accessed concurrently.
Still I do think it would be possible to either fix the results hash
issue (which would be great!) or manage the multi-threaded access
issues in a queue manager worker yourself.
For my immediate needs, I punted and just store the queue of things to
be worked on in the db, and let the db server deal with the
concurrency issues. I agree it is a less than ideal solution - but
given my options and other priorities it was a quick easy fix to a
hairy problem. Perhaps a lightweight db like SQLite could be used just
to manage the queue -- and thereby offload the traffic from the main
db, while also saving the need to deal with the concurrency headaches.
(I've never used SQLite, so I'm not sure).
More information about the Backgroundrb-devel