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

I've created a small web application/form to allow clients to input DNS requests. It is written in CGI::Application and has 3 modes... "summary" (main_handler), "submit" (submit_req), and "approval" (mail). Via inheritence, I'm also using HTML::Template to segregate the html.

Here's the problem... this script works great when run via standard CGI/perl. However, whenever I try to run it via mod_perl, it appears that the DBI responses are being cached in a mod_perl thread (or whatever it uses). This is a bad thing. FWIW, using (or not using) Apache::DBI doesn't make a difference.

Here's the pattern I've noticed when creating a series of sequential records (1st is A, 2nd is B, etc.). After restarting the named processes, everything works ok up until the 5th instance (E)...

a b c d
a a b c d e
a b a b c d e f
a a b c d e a b c d e f g
a b a b c d e f a b c d e f g h

As you can see, the data is "in there", but it's being prepended by some sort of random(?) cached data. The database does not reflect this odd behavior... everything is kosher in the table.

I've added the entire package to fuzzyping's scratchpad. If there are specific portions of the code, or of the base cgi, HTML templates, or database structure that anyone would like posted here, please let me know. Thanks in advance for everyone's help!

-fuzzyping

Replies are listed 'Best First'.
Re: perl_mod caching DBI responses
by Juerd (Abbot) on Jul 02, 2002 at 14:22 UTC

    However, whenever I try to run it via mod_perl, it appears that the DBI responses are being cached in a mod_perl thread (or whatever it uses). This is a bad thing. FWIW, using (or not using) Apache::DBI doesn't make a difference.

    This "Bad Thing" (which it is not) comes forth from not using strict, and more directly from using global variables. With mod_perl, global variables are persistent for the interpreter is embedded in Apache itself and will not exit until Apache exits. When programming for mod_perl, ALWAYS use strict! (Actually, remove "When programming for mod_perl, " and just always use strict.)

    You can't get away with sloppy programming in mod_perl. Find more information about mod_perl before doing anything with it, as incorrect use may fry your Apache. 

    - Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

[reply]
      Thanks Juerd! Yes, this fixed everything. I was not aware of that problem with globals and mod_perl. First, I was mistaken in thinking I *was* using strict properly. I was actually calling it from the base cgi, rather than the package (and assuming it would affect both). :-(

      Second, I did not mean to let those few globals slide through. Because I accidentally wasn't using strict correctly (this is the first package I've ever written), I wasn't getting any scoping errors... as you can see by the rest of my code, I made an honest attempt at scoping properly.

      Anyhoo, thanks again! w00t!!!

      -fuzzyping
[reply]
        I was just about to post a list of globals in your code, but I see you've already got it covered. Congrats on getting it working, and improving your coding style.

        You can read about issues with globals and other things in the mod_perl guide. By the way, this is what I meant about possibly using Apache::PerlRun instead of Apache::Registry. Apache::PerlRun will clear globals, which would have made your code work, but it's not as fast because of this.

[reply]

Back to Seekers of Perl Wisdom