mod_perl works by wrapping every Perl script in a routine called handler inside the package based on the name and path of the script. Instead of starting a new process to run each script, this handler routine is called by one of several constant Perl attacks.
Usually this knowledge will help a lot to understand the changes in the environment from mod_cgi, but since you have never added use strict to your programs and are not familiar with the work of declared variables, you have a lot of catch-up!
The mod_perl environment can cause non-obvious security breaches, and you should now start with use strict on each script and declare each variable. use Carp will also help you understand error logs.
The variable name declared with our is a synonym with a lexical scope for a package variable with the same name that can be used without a full definition of the name, including the package name. For example, usually a variable declared with our $var provides access to the scalar $main::var (if there was no package declaration earlier) without specifying main:: . However, such variables that started life with the undef value in mod_cgi now retain their values from the previous execution of any given mod_perl stream, and for consistency it is most safe to always initialize them at the declaration point. Also note that the default package name is no longer main due to the wrapping that mod_perl does, so you can no longer access package variables using the main:: prefix, and it is not wise to find the actual package name and use it explicitly because it will be a very long name and will change if you move or rename your script.
A my variable is one that exists independently of the package symbol table, and usually its lifetime is the execution time of the attached file (for variables declared in the file area) or subroutine. They are safe in mod_perl if they are declared and used in the scope of the contents of the script file or completely within the same routine, but you can be stung if you scope and declare my $global in the scope of files, and then try to use it in the routine. The reason for this is not simple, but it is because mod_perl wraps your script in the handler routine, so you have subroutine declarations. The internal routine will tend to accept only the first instance of $global and ignore any others created by later handler calls. If you need a global variable, you must declare it with our and initialize it in this declaration, as described above.
A local variable is very similar to our in that it forms a synonym for a package variable. However, it temporarily stores the current value of this variable and provides a new copy for use until the end of the block area or region. Due to its automatic creation and deletion within its scope, it can be a useful alternative to the my variable in mod_perl scripts, especially if you use pointers to data structures, such as an instance of the CGI class. The declaration our $cgi = CGI->new correctly create the object, but due to persistence, mod_perl would leave it in memory until the next execution of the thread removes it to make room for another.
Regarding your questions:
Using a variable without declaring it results in a compile-time error if use strict in place, as it should be. Otherwise, it is synonymous with this variable in the current package namespace.
Variables are either package variables or lexical variables; there is no way to declare a variable as private as such. Lexical variables (declared using my ) will be created and destroyed each time the script is executed, unless you create an invalid closure, as described above, by writing a subroutine that uses a variable declared in a wider scope when the variable is constant, but will not do what you want. A variable declared with our will retain its value when the script is called, and a variable declared with local will be destroyed when the script ends. Both our and local variables are package variables, and all references to the same variable name refer to the same variable.
To declare a variable that is always available everywhere in any script call, you can use the local variable or the initialized our variable. In the file area, local $global is pretty much equivalent to our $global = undef for mod_perl scripts. If you use our variable to point to a data structure, then remember to destroy it at the end of the script with undef $global .
my variables are unique and visible inside the block in which they are declared, whether it be a block within if , while or for , or even just the bare { ... } block size. Always use my variables for temporary working variables that are only used inside the block and are accessible from nowhere.
I hope this helps