The scope of a variable declared with my or local ends at the end of the enclosing [+/- ... -/+] block; the [+/- ... -/+] blocks act much like Perl's { ... } in that regard.

Global variables (everything not declared with my or local) will be undef'ed at the end of each request, so you don't need to worry about any old variables laying around and causing suspicious results. This is only done for variables in the package the code is eval'ed in -- every variable that does not have an explicit package name. All variables with an explicit package name (i.e., in modules you use) will stay valid until the httpd child process dies. Embperl will change the current package to a unique name for every document, so the influence between different documents is kept to a minimum. You can set the name of the package with EMBPERL_PACKAGE. (See also (Safe-)Namespaces and opcode restrictions.)

Since a CGI script is always a process of its own, you don't need to worry about that when you use Embperl as a CGI script.

If you need to declare variables which need to live longer than just one HTTP request (for example, a database handle), you must either put it's name in the hash %CLEANUP or declare them in another package (i.e., $Persistent::handle instead of $handle).

If you want to use the strict pragma, you can do this by using the var metacommand to declare your variables.

NOTE: Bacause Apache::DBI has its own namespace, this module will work together with Embperl to maintain your persistent database connection.

You can disable the automatic cleanup of global variables with EMBPERL_OPTIONS or the cleanup parameter of the Execute function.

You can define exceptions to the cleanup rule with the hash %CLEANUP.

If you like to do your own cleanup you can define a subroutine CLEANUP in your document. This will be called right before the variables are cleaned up, but after the connection to the client is closed.

 EXAMPLE:

  [! sub CLEANUP { close FH ; } !]