You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Craig Tussey <ct...@yahoo.com> on 2006/10/05 20:56:40 UTC

Code Serialization and mod_perl

Hello,

Please help me understand how Perl with mod_perl
handles the following situation. Consider 2 clients
out in the WWW using the same form to work on 2
different records of the same type. At submission, the
form executes a database function and passes the data
entered using the form. The function retrieves the
data from the CGI-like connection, assigns the data to
Perl dataspaces and begins processing the code series
of the function. Now the 2nd client executes the
function in the same way, right on the heels of the
1st client.

In the C language in a network environment, when a
client calls a database function in a DLL to access a
server database, a system semaphore is is used to
serialize code access to prevent the corruption
ofdataspaces.

With only Perl, a different Perl interpreter instance
is started for each CGI request.   The instances don't
know about each other and dataspaces are unique to an
instance.

How does Perl with mod_perl handle this. Are there any
important differences with the only Perl situation.
Might the dataspaces be corrupted? How does this work?

My technical environment is Windows XP Home, Apache
2.0.049, Perl 5.8.3, and mod_perl 2.0.2. Thank you in
advance for any responses. I appreciate your time.

Craig Tussey
ct8638@yahoo.com



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Code Serialization and mod_perl

Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2006-10-05 at 11:56 -0700, Craig Tussey wrote:
> With only Perl, a different Perl interpreter instance
> is started for each CGI request.   The instances don't
> know about each other and dataspaces are unique to an
> instance.
> 
> How does Perl with mod_perl handle this.

In exactly the same way.  The interpreters are in separate processes or
threads and share nothing.  The only exception is if you run mod_perl 2
using threads and intentionally share some variables.

> Are there any
> important differences with the only Perl situation.

Not in terms of separation between instances.  There are issues with
code that doesn't clean up after itself (e.g. using global variables
instead of lexical ones) since the interpreters do not exit after each
request the way they do in CGI.

- Perrin


Re: Code Serialization and mod_perl

Posted by Jonathan Vanasco <mo...@2xlp.com>.
On Oct 5, 2006, at 2:56 PM, Craig Tussey wrote:
> How does Perl with mod_perl handle this. Are there any
> important differences with the only Perl situation.
> Might the dataspaces be corrupted? How does this work?

variables will persist through  every connection...

so 'use strict()' and specifically declare every variable with my /  
our as appropriate

ie:

my $connected= 0;
sub connect {
	my $connection= 'dbi connection';
	$connected++;
	return $connection
}
sub handler{
	my $r= shift
	if ( ! $connection ) {
		$connection= connect()
	}
	print $connected;
}

the first time you run that, you'll call connect and increment  
connected,  which is local to the package.  the second time though,  
$connection will have been set within the handler block

and then everything that David Nicol said

Re: Code Serialization and mod_perl

Posted by David Nicol <da...@gmail.com>.
On 10/5/06, Craig Tussey <ct...@yahoo.com> wrote:
> Please help me understand mod_perl

> With only Perl, ... the instances don't
> know about each other and dataspaces are unique to an
> instance.
>
> How does mod_perl handle this. Are there any
> important differences with the only Perl situation.

any introduction to mod_perl should tell you that some
of the data may persist between request events while some
is per-request.  Database connections in particular may
pooled and conserved.

Understanding these subtleties to avoid data corruption issues
such as you are legitimately concerned about is why
the competent mod_perl developers can demand the big bucks.

http://www.google.com/search?q=introduction+to+mod_perl
is a good starting point for starting points.

Have a nice day.