in reply to Cron Jobs and mod_perl...

I cannot wrap my brain around this, why do you need to run it under mod_perl?

You're best solution would be to port whatever is mod_perl dependent and make it not so (you crazy).

On the other hand, why is it mod_perl dependent? (what portion of the mod_perl functionality is it exploiting)

Can you take advantage of Apache::FakeRequest?

I seriously see a conflict of interest here. Whatever part of your mod_perl script that you need to run from cron should be extracted into its own package.

Anyway, that's just my shot in the dark, later


MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
** The Third rule of perl club is a statement of fact: pod is sexy.

Replies are listed 'Best First'.
Re: Re: Cron Jobs and mod_perl...
by cLive ;-) (Prior) on Dec 14, 2002 at 01:24 UTC

    "why do you need to run it under mod_perl?"

    Laziness.

    I'd rather keep one module going than split it into two.

    I guess I'll just eval the use statements for Apache and Apache::DBI, and rewrite my DB subroutines (lazily written because Apache:DBI takes over connect and disconnect methods - long story....).

    Unless anyone has a better idea?

    .02

    cLive ;-)

      I always thought that Apache::DBI overloaded the DBI::connect and DBI::disconnect functions to enable persistent connections under mod-perl and did not really change anything how you programmed the DBI-interface. So if you drop all reference to Apache::DBI and use the correct DBI/DBD combo the program should keepon working.

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

        The point was, since I was using Apache::DBI, I lazily coded the DB methods - ie, connected and disconnected from the DB each time a DB call was made in the script, since I knew Apache::DBI would ignore that and keep the connection open.

        And since some of the cron strips would be running hundreds of DB querires, I wanted to keep that system in place for it, rather than rewriting the module to work well outside of mod_perl...

        .02

        cLive ;-)