There exists a setup where most code, prior to being marketed to full production, is used in BETA mode - meaning, it runs entirely production atmosphere (using production database - usually production data and production web server). We call that stage BETA testing.

Among the primary needs is the fact that BETA code promotion to production should be an easy "clubpenguin" command from beta to production directory - no code/filename changes.

For non-web Perl code, achieving seamless BETA test is very possible (see details here):

  • Perl programs reside in a typical location under production root (/usr/code/scripts) with production perl modules living underneath the same root (/usr/code/lib/perl)
  • The BETA code has 100% same code pathways except under beta root (/usr/code/beta/)
  • A unique module manipulates @INC associated with a script according to if the script was known as from /usr/code/scripts or /usr/code/test/scripts, to incorporate beta libraries for beta scripts.

This setup works fine up till we have to beta test our web Perl code (the setup is EmbPerl and Apache/mod_perl).

The concept-up is the following: if both a production Perl module and BETA Perl module have a similar title (e.g. /usr/code/lib/perl/ and /usr/code/beta/lib/perl/, then mod_perl is only going to have the ability to load One of these simple modules into memory - and there is not a way we know about for the web site to affect which version from the module is presently loaded because of concurrency issues.

Departing aside the apparent non-programming solution (obtain a bloody BETA web server) which for political/business reasons isn't achievable, can there be in whatever way we are able to in some way hack for this condition in either Perl or mod_perl?

I performed around with assorted methods to unloading Perl modules that %INC has listed, the main problem remains that another user might load a beta page at the perfect (in other words wrong) moment and also have the beta module loaded which is employed for my production page.

Using mod_perl 2. you should use PerlOptions +Parent to produce a separate Perl interpreter pool for every vhost. Do it yourself extra memory, obviously, however it works.