isync has asked for the wisdom of the Perl Monks concerning the following question:

I am in the process of using CGI::Application under FastCGI.
So far I have tried:
use CGI::Fast; while (my $q = new CGI::Fast){ my $app = new MyCGIApplication(QUERY => $q); # this is your CGI::App m +odule $app->run(); }
as proposed at link and link. What I found out is that this approach executes cgiapp_init() and setup() on *every* request (which isn't desireable as I load my templates there, establish caches etc and these steps should run only once!).

My second try was CGI::Application::FastCGI, which gets the flow of execution right (with executing setup and cgiapp_init only once), but seems to have some garbage-collection issues (which also the cpan bugtracker tells me).
As I understand it, this is due to the fact that CGI::Application::FastCGI does not create a new CGI::Application object for every request. To heal this, link suggests doing
$self->{__PARAMS} = {}; $self->header_type('header'); $self->header_props( {} );
in cgiapp_postrun() as a kind of garbage-collection. But what it does: it also wipes all my $self->params which I use as constants/configuration throughout the script. Any comments?


At link are talks about establish things like connecting the DB etc (which shoud normally happen in setup() or cgiapp_init() ) outsite the fcgi loop and then enter the Application (which I don't fully understand btw..)

Now, which way is the "CGI::Application way" of doing things and getting it right? Can somebody shed some light and give insight on how to get fcgi working on a script which should go, after an expensive init phase, into a proper runmode-loop.

Replies are listed 'Best First'.
Re: CGI::Application under FastCGI (Guru advice needed)
by samtregar (Abbot) on Nov 28, 2007 at 19:57 UTC
    What I found out is that this approach executes cgiapp_init() and setup() on *every* request (which isn't desireable as I load my templates there, establish caches etc and these steps should run only once!).

    CGI::App definitely needs to get re-initialized for each request. Even if you could find a way to work-around the problems you've found so far you'd end up getting burned again the first time you tried to use a plugin that needed per-request initialization.

    So, instead of hacking CGI::App, hack your code. In your setup() you could do something like:

    our $INIT_DONE; unless ($INIT_DONE++) { # do some cache init, or whatever ... }

    That way you can do your one-time-only initialization in your setup and it will only happen the first time through.

    -sam

      Thanks for your idea! You comment made me decide for this design!
      Actually I saw this flag-todo-done approach in another C::A::Plugin module yesterday and thought it is an ugly hack. I still hoped there was a way to do it elegantly...

      BTW: Since I switched to C::A (to finally get cgi right, as they said) it was just a trial of hacks and tricks to get it working like my old homebrewn framework. Mmh. I shouldn't complain...
        Too ugly? Perhaps - beauty is in the eye of the beholder. A "cleaner" way to handle one-time cache setup is by using the singleton object pattern. It's more code, but you won't have to see anything "ugly" in your C::A sub-class.

        -sam