Jen, I don't have an answer but I do have a few suggestions.
At 11:22 AM -0500 3/21/03, [EMAIL PROTECTED] wrote: >We're running: >OpenVMS 7.2-1 >Compaq Secure Web Server (CSWS) 1.2 (based on Apache 1.3.20) >Perl 5.6.1 (gotten from Compaq's site) >CSWS Perl V1.1 (based on mod_perl 1.25) Note that all of those things are supported by HP, >DBI 1.201 >DBD::RDB 1_15 whereas whatever support there is for these will be here and/or on the dbi-users list, >RDB V7.0-31 and of course this is supported by Oracle. Determining which component is really having the problem might be your first step in getting a resolution. >We are using the RDB module in Perl to access an RDB database on the >same machine. The problem that I'm having is that if there is an >error in the script after the connect statement, then Apache will >stay connected to the database indefinately. Without more detail it's impossible to say with certainty where the problem is. I would start by examining the script for proper error handling. Ideally the script should detect errors and (depending on the script's design) possibly disconnect from the database rather than simply blowing up, exiting early, or looping to get the next request. Perhaps it disconnects at the end of a successful run but possibly (just a guess) neglects to disconnect when it encounters an error? Do you have a 10-20 line reproducer that illustrates the problem? What exactly do you mean by "an error in the script"? >If Apache is not restarted to get it to detach from the database, >then it will eventually lock up RDB to the point that no one will be >able to access any of the databases. What can I do to keep this >from happening? There may be some less drastic managerial mechanisms for getting unhung when this is going on. I'm quite rusty on Rdb and never really dealt with it from the DBA perspective, but there's got to be a way for the DBA to view what connections are active and disconnect one that is causing trouble. For Apache, it's probably possible to shut down one of the APACHE$xxxxx processes without restarting the whole server, but check your docs and/or other support channels on that. Don't neglect standard analytical tools to examine the state and resource consumption of the database connection and associated web server process. Depending on the origin of the problem these may give insight into it, or they may be red herrings and only show the consequences of the problem and not the problem itself. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
