A pretty good representation of my needs, the database polling is nearly
instantaneous.   And the actions to be performed upon polling aren't very
long either (but I suppose I could fork off the work).

> I may have missed something in this thread, but it seems like overkill
> to use a Wheel::Run to handle the polling of the database. Assuming each
> poll doesn't have to reconnect to the database (which would be rather
> silly, unless you are testing the actual connection) and if the polling
> operation was not significantly lengthy (which if it is then is it
> really a suitable polling design or should there not be a trigger on the
> front end?)  then to me there doesn't seem to be a reason to fork the
> process.  Instead I would fork the actual work that needs to occur when
> the polling actually turns something up, as the fork/work should be the
> slow part of the process rather than the polling?  The other reason to
> fork was to make absolutely sure not to miss a polling interval, etc.
> but unless the processing has to be serial (which moots the discussion)
> and/or real time (in which case I would be surprised if Perl was used at
> all) then even if one polling interval was delayed or droppped because
> some other part of the process delayed it, it shouldn't matter.  Granted
> I don't know your exact needs, the one application I have built with POE
> contains a main controller that spawns sessions to handle directory
> polling, 1 directory per session polling each second with 45+
> directories being polled, to the best of my knowledge it has never
> skipped a beat. When the directory contains a file (aka the polling
> noticed something new) a Wheel::Run is spawned to handle the file
> (encrypt it (slow process, relatively) and send it on its way (a really
> slow process, relatively). This scheme has worked very well, granted a
> database statement is (most likely) slower than a simple readdir on the
> local filesystem, but I would give it a shot before going down the route
> of the Wheel::Run.
>
> Sorry I can't post code, I am *still* working on that (getting to post
> it, not the code)...
>
> http://danconia.org
>
>

Reply via email to