-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

I recommend ditching Apache::Registry and jumping into the real mod_perl by writing a module instead of just dropping a script in a playpen and hoping that it plays nice with the other 'children'. Grab a copy of the mod_perl Developer's Cookbook, it is invaluable.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

And I highly recommend following the advice given in this book to read the Eagle Book cover to cover, twice.

You might be running into variable persistance. If your variables are globally scoped, they'll hold their values between page loads.

Another common problem is declaring a lexically scoped variable and then trying to use it in a subroutine, e.g.

my $foo = "bar";

sub foo
{
    # It's ok to use $foo here in a normal script,
    # but it may have strange results under mod_perl
    print $foo;
}
[download]

Post the relevant section of code, and we can probably help you out.

-Matt

You can quickly mode that old Perl CGI script to mod_perl by using the Apache::PerlRun module. The performance benefits are good but not outstanding.

The difference between Apache::PerlRun and Apache::Registry is that the former scrubs the namespace between runs.

It really sounds like you have been hitting your head against some really basic and well-known mod_perl things. So the last post about RTFM is an extremely good idea. Mod_perl requires a bit of reading when you start and then some experimentation until you get used to it.

Regarding your questions:

1. mod_perl embeds a single persistent perl interpreter instance in apache as opposed to launching a new one each time a page is opened. So you typically use a parent program (launched once when the server is soft-restarted) and a child program (called from a browser, but also sharing the memory of the parent).
2. This means if you use global variables they will clobber you right on the head, being shared across all calls to one or all of the apache server child processes. one of the very first programming examples (a counter) in the docs does what you are talking about. (hint: use lexicals)
3. Likewise with database connections, if you happen to open a db connection in your child code it will stay open. probably would work if you undef'd it but you can also open a connection in the parent, there is in fact a connection pool module for this purpose. read about it.
4. In general the really extremely good advice is to use strict. mod_perl *will* have your brain for breakfast if you do not use strict. 'nuf said.
5. If you are porting from CGI there is also good documentation in the same place on porting from cgi.

#!/usr/bin/perl -W

use CGI qw(param);
use CGI::Carp qw(fatalsToBrowser);
use DBIx::FullTextSearch;
use DBIx::FullTextSearch::StopList;
use DBI;
use HTML::Template;
use HTML::Template::Expr;

my $dbh = DBI->connect('dbi:mysql:search','??????','??????') or die("C
+ould not connect to database");
my $cbh = DBI->connect('dbi:mysql:cobra3','??????','??????') or die("C
+ould not connect to database");
my $search = param("search_string");
my $fts = DBIx::FullTextSearch->open($dbh, '??????');

my @files = $fts->search($search);

if (@files)
{
    foreach $filename(@files){
      $filename = substr($filename,0,-4);

      my $sth = $cbh->prepare("SELECT id, title, summary FROM  resourc
+e WHERE id =?");
      $sth->execute($filename);

        while (my $ref = $sth->fetchrow_hashref()){

        my $title = $ref->{title};
        my $id = $ref->{id};

        push @rows, { ID => $id, TITLE => $title };

    }
  }
}

my $template = HTML::Template->new(filename => 'ee_search.tmpl');

$template->param(SEARCH_STRING => $search);
$template->param(ROWS => \@rows);

print "Content-type: text/html\n\n";
print $template->output;
[download]

strict is your friend. :) It's telling you that you need to explicitly scope $filename and @rows. Try this:

my @rows;

if (@files)
{
[download]

    foreach my $filename(@files){

      $filename = substr($filename,0,-4);

      my $sth = $cbh->prepare("SELECT id, title, summary FROM  resourc
+e WHERE id =?");
      $sth->execute($filename);

        while (my $ref = $sth->fetchrow_hashref()){

        my $title = $ref->{title};
        my $id = $ref->{id};

        push @rows, { ID => $id, TITLE => $title };

    }
  }
}

my $template = HTML::Template->new(filename => 'ee_search.tmpl');

$template->param(SEARCH_STRING => $search);
$template->param(ROWS => \@rows);
[download]

-Matt

In a way, use strict is more important than warnings.

Hi ,

The use strict pragma is important as your program runs through mod-perl as mod-perl behaves negatively if you have variables that are global without scope and as you know use strict will surely not entertain global variables

Not quite correct. It will not entertain undeclared global variables. (Or undeclared lexical variables, for that matter, but AFAIK a variable has to be declared to be lexically scoped anyway.)

Do you mean it ran out of MySQL connections? Your code as it stands should not be using more connections than it was when running as a CGI. Are you using Apache::DBI?

Please go to

http://perl.apache.org

and read all the mod_perl documentation there.