RE: Using a module that is not quite mod_perl compliant

[Goehring, Chuck Mr., RCI - San Diego]

Perrin,

Thanks, I should have known that, but I haven't had this problem before.

Chuck


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 26, 2002 7:48 PM
To: Goehring, Chuck Mr., RCI - San Diego
Cc: [EMAIL PROTECTED]
Subject: Re: Using a module that is not quite mod_perl compliant


> If a third-party module uses global variables internally that causes
> persistence of the data under mod_perl, is there a fix.

You can manually clear them in a cleanup handler.  If they're in a
separate package, you can clear the whole namespace of the package.  Take
a look at the code for this in Apache::PerlRun.
- Perrin

Re: Using a module that is not quite mod_perl compliant

[perrin]

> If a third-party module uses global variables internally that causes
> persistence of the data under mod_perl, is there a fix.

You can manually clear them in a cleanup handler.  If they're in a
separate package, you can clear the whole namespace of the package.  Take
a look at the code for this in Apache::PerlRun.
- Perrin

Using a module that is not quite mod_perl compliant

[Goehring, Chuck Mr., RCI - San Diego]

To the list of mod_perl experts,

If a third-party module uses global variables internally that causes persistence of 
the data under mod_perl, is there a fix.  This particular module has a lot of 
dependencies on other modules, so "fixing" the third-party stuff may not be practical. 
 It really saves me a lot of work, but I obviously can't use it if I'll have 
multi-user data corruption.

Currently running on Win2000, Apache 1.3.12 and mod_perl 1.24, perl 5.6.0.  It is a 
cgi that runs under Apache::Registry.  It doesn't do any of the exotic "handler" stuff 
that mod_perl does - it's just a cgi that queries Oracle.


Any canned solutions to this type of problem?  Would moving my code to a module help?


Thanks
Chuck Goehring