I'm getting the feeling that we may have problems in more than one area. I am new to most of this, so I am learning as I go.
I can give you an example of when Apache will stay connected. If I connect to the database and, before the disconnect, I have a
call to a subroutine that does not exist, then the script will blow up. So, it never gets to the disconnect statement resulting in
the Apache process staying attached to the server. In a case like this, it may just have been a typo, but the programmer that wrote
the script probably is not authorized to stop the Apache processes. The more I think about it, I may end up having to contact
Oracle to find out if there is a way to keep any single process from being connected to the database over a specified amount of
time.
Dunno about RDB, but plain Oracle does have a timeout parameter the server can set on the connection.
Apache can also have timeouts on individual mod_perl processes (and Apache processes in general) that will shoot processes after a while, you might want to take a look at that.
Below is a part of a script that if ConvertNumToDate() is not in the package UTILITIES, then the script would never detach from the
database.
my $dbh = DBI->connect("dbi:RDB:ATTACH FILENAME meltdbdir:melt_rdb") or die "Can't connect to Melt Shop database: $DBI::errstr\n";
That ought to go out of scope when the program errors out, and get cleaned up after. That it isn't makes me think there's something odd going on. Try setting the logica PERL_DESTRUCT_LEVEL to 2, in some logical table that the Apache process can see and see what happens. I don't remember off-hand if mod_perl overrides this, but it might help in the short term, at least until a better solution can be found.
Is this program a mod_perl handler, a plain CGI program running under mod_perl, something using Apache::Registry, or somethin gelse?
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
