You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by John Dunlap <jo...@lariat.co> on 2014/02/02 02:14:15 UTC

Singleton Persistence

In mod_perl, can instantiated singletons survive requests? I'm asking
because I appear to have one which *appears* to be bouncing back and forth
between virtual hosts as perl interpreters are recycled. Is this possible
and, if yes, how do I prevent it?

Cheers!
John

Re: Singleton Persistence

Posted by Perrin Harkins <ph...@gmail.com>.
On Sat, Feb 1, 2014 at 8:14 PM, John Dunlap <jo...@lariat.co> wrote:
> In mod_perl, can instantiated singletons survive requests?

Sure, anything you put in a global will survive until the httpd child
process is shut down.  How many requests each child serves depends on
your configuration.  When a new child starts up, it will have the same
state as the parent process, so if you put something into a global in
the parent, it will be there in the children.  There is no sharing
between processes though, so changes in a child process will not be
reflected in the other processes or in newly spawned ones.

- Perrin

Re: Singleton Persistence

Posted by John Dunlap <jo...@lariat.co>.
In the solution that I ended up using, the singleton in question contains
the reference to IOC::Container, which contains service literals for each
of the constants which are available in $apache->dir_config. As a
performance enhancement, when I attempt to retrieve an object from the
container, I check the server hostname against the hostname in the
container and only reinitialize the container if they don't match. This
avoids reinitializing the container if it happens to be sequentially used
in the same virtualhost multiple times. I suppose I could have built a more
sophisticated caching system which stores container instances in a hash and
retrieves the correct one by hostname but I didn't feel like spending the
time and it seemed like a more fragile approach than I'm comfortable with.

if (is_isa($apache, 'Apache2::RequestRec')) {
my $server_hostname = $apache->server->server_hostname;
my $container_hostname = $container->get('hostname');
if ($server_hostname ne $container_hostname) {
$container->{C} = undef;
$container->_init_components($apache);
}
}



On Thu, Feb 27, 2014 at 12:34 PM, Rolf Schaufelberger <rs...@plusw.de> wrote:

> Hi,
>
> we are using Class:Singleton , yet we manually destroy the singleton at
> the beginning of each request before we create a new one.
> So I have a class PW::Application which isa Class::Singleton  and then
>
>     {
>         no strict 'refs';
>         ${"PW::Application\::_instance"}= undef;
>     }
>     $self->{appl}= PW::Application->instance($param{base});
>
> I tried Apache::Singleton before, but, as far as I can remember,  it
> didn't work with mp2.
> So why are we using a singleton ? Well  , our app does not  only  consist
> of the web part , we also have many scripts running that are part of the
> application, and we put things like DBIx::Class schema object, config,
> current user etc in our singleton and so we can access these data  the same
> way, neither if we run a function from web interface or from command line.
> Since we don't have heavy  load on our apps creating this singleton with
> every request works for me .
>
>
>
> Am 02.02.2014 um 02:14 schrieb John Dunlap <jo...@lariat.co>:
>
> > In mod_perl, can instantiated singletons survive requests? I'm asking
> because I appear to have one which *appears* to be bouncing back and forth
> between virtual hosts as perl interpreters are recycled. Is this possible
> and, if yes, how do I prevent it?
> >
> > Cheers!
> > John
>
>
> Rolf Schaufelberger
>

Re: Singleton Persistence

Posted by Rolf Schaufelberger <rs...@plusw.de>.
Hi, 

we are using Class:Singleton , yet we manually destroy the singleton at the beginning of each request before we create a new one. 
So I have a class PW::Application which isa Class::Singleton  and then 

    {
        no strict 'refs';
        ${"PW::Application\::_instance"}= undef;
    }
    $self->{appl}= PW::Application->instance($param{base});
 
I tried Apache::Singleton before, but, as far as I can remember,  it didn’t work with mp2.
So why are we using a singleton ? Well  , our app does not  only  consist of the web part , we also have many scripts running that are part of the application, and we put things like DBIx::Class schema object, config, current user etc in our singleton and so we can access these data  the same way, neither if we run a function from web interface or from command line.  
Since we don’t have heavy  load on our apps creating this singleton with every request works for me .



Am 02.02.2014 um 02:14 schrieb John Dunlap <jo...@lariat.co>:

> In mod_perl, can instantiated singletons survive requests? I'm asking because I appear to have one which *appears* to be bouncing back and forth between virtual hosts as perl interpreters are recycled. Is this possible and, if yes, how do I prevent it?
> 
> Cheers!
> John


Rolf Schaufelberger

Re: Singleton Persistence

Posted by Chris Bennett <ch...@bennettconstruction.us>.
On Tue, Feb 04, 2014 at 11:42:43AM +0100, Vincent Veyron wrote:
> Le lundi 03 février 2014 à 19:13 -0500, Perrin Harkins a écrit :
> > On Mon, Feb 3, 2014 at 5:33 PM, Chris Bennett
> > <ch...@bennettconstruction.us> wrote:
> > > Right now I am using pg_1_.pl and pg_2.pl on the different hosts, but
> > > the code is identical, except that some data is pulled in from a config
> > > file for the different databases, etc used.
> 
> > I'm sure that you can use the same code, but the question is how do
> > you know which data to pull in and how do you store it in perl data
> > structures?  One common approach in this situation is to use
> > PerlSetVar inside your virtualhost config to set something you can
> > read from perl that will tell you which virtualhost you're in.  
> 
> Hi Perrin,
> 
> $r->hostname() will tell you which virtualhost you're in.
> 

That should work.

> legalcase.libremen.com (English version) shares the same code as 
> litigios.libremen.com (Spanish version). Each virtualhost has its own
> database, configured with PerSetVar, as Perrin said.
> 
> You can see it in action with the demo account.
> 

I will go look at your sites. Since I speak both English and Spanish, I
can look at both.

I will try these suggestions.
I have 3 databases that I use in production with password access and
demo versions on the other site.
I don't want anyone getting access to my production databases
since insert, update and delete are options. 

Thanks,
Chris Bennett

> 
> -- 
>                                         Regards, Vincent Veyron 
> 
> http://libremen.com/ 
> Legal case, contract and insurance claim management software
> 

Re: Singleton Persistence

Posted by Vincent Veyron <vv...@wanadoo.fr>.
Le lundi 03 février 2014 à 19:13 -0500, Perrin Harkins a écrit :
> On Mon, Feb 3, 2014 at 5:33 PM, Chris Bennett
> <ch...@bennettconstruction.us> wrote:
> > Right now I am using pg_1_.pl and pg_2.pl on the different hosts, but
> > the code is identical, except that some data is pulled in from a config
> > file for the different databases, etc used.

> I'm sure that you can use the same code, but the question is how do
> you know which data to pull in and how do you store it in perl data
> structures?  One common approach in this situation is to use
> PerlSetVar inside your virtualhost config to set something you can
> read from perl that will tell you which virtualhost you're in.  

Hi Perrin,

$r->hostname() will tell you which virtualhost you're in.


@Chris :

>
> Can I safely use pg.pl on both VirtualHosts or do I need to do
>something
> > else also to do this?
> 

I use this for the site that you see in my sig. 

legalcase.libremen.com (English version) shares the same code as 
litigios.libremen.com (Spanish version). Each virtualhost has its own
database, configured with PerSetVar, as Perrin said.

You can see it in action with the demo account.


-- 
                                        Regards, Vincent Veyron 

http://libremen.com/ 
Legal case, contract and insurance claim management software


Re: Singleton Persistence

Posted by Perrin Harkins <ph...@gmail.com>.
On Mon, Feb 3, 2014 at 5:33 PM, Chris Bennett
<ch...@bennettconstruction.us> wrote:
> Right now I am using pg_1_.pl and pg_2.pl on the different hosts, but
> the code is identical, except that some data is pulled in from a config
> file for the different databases, etc used.
>
> Can I safely use pg.pl on both VirtualHosts or do I need to do something
> else also to do this?

I'm sure that you can use the same code, but the question is how do
you know which data to pull in and how do you store it in perl data
structures?  One common approach in this situation is to use
PerlSetVar inside your virtualhost config to set something you can
read from perl that will tell you which virtualhost you're in.  Then
you can use that as a key into a data structure or for triggering
conditional behavior.

- Perrin

Re: Singleton Persistence

Posted by Chris Bennett <ch...@bennettconstruction.us>.
On Mon, Feb 03, 2014 at 04:44:01PM -0500, John Dunlap wrote:
> My current workaround is using this option in my apache configuration,
> PerlOptions +Parent
> 
> to make sure that interpreters aren't shared between virtualhosts. However,
> this isn't good from a resource sharing perspective so it sounds like I may
> need to re-architect some of my code.
> 

Maybe this is the right thread for this question.
I am sharing my .pm modules with several VirtualHosts.
Using Apache 1.3* and mod_perl 1.

Right now I am using pg_1_.pl and pg_2.pl on the different hosts, but
the code is identical, except that some data is pulled in from a config
file for the different databases, etc used.

Can I safely use pg.pl on both VirtualHosts or do I need to do something
else also to do this?
Thanks,
Chris Bennett

> 
> On Mon, Feb 3, 2014 at 4:30 PM, Vincent Veyron <vv...@wanadoo.fr> wrote:
> 
> > Le samedi 01 février 2014 à 20:14 -0500, John Dunlap a écrit :
> > > In mod_perl, can instantiated singletons survive requests? I'm asking
> > > because I appear to have one which *appears* to be bouncing back and
> > > forth between virtual hosts as perl interpreters are recycled. Is this
> > > possible and, if yes, how do I prevent it?
> > >
> >
> > Showing some code exhibiting the behaviour would help. You probably hit
> > something similar to this :
> >
> > http://perl.apache.org/docs/1.0/guide/porting.html#An_Easy_Break_in
> >
> > In any case, a singleton resides in the perl interpreter, which is used
> > by apache's child process to serve many requests, so it will survive
> > requests.
> >
> > You can do this however (I don't remember the exact parameter just now,
> > it's in the doc or the archives) :
> >
> > http://perl.apache.org/docs/2.0/user/design/design.html#Virtual_Hosts
> >
> > --
> > http://libremen.com
> > Gestión de litigios y de expedientes de seguros de siniestros para el
> > servicio jurídico
> >
> >

Re: Singleton Persistence

Posted by Vincent Veyron <vv...@wanadoo.fr>.
Le lundi 03 février 2014 à 21:49 +0000, John ORourke a écrit :
> I do it by treating the request as something transient - in other
> words assuming that interpreter state is maintained between requests,
> and resetting or recreating all the objects I use to process the
> request in my fixup handler.
> 


pnotes is very handy to pass structures across all phases of a request.

I use PerlHeaderParserHandler :
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlHeaderParserHandler

In this I write :

my $dbh = DBI->connect_cached( "proper connection string here") ;

$r->pnotes( 'dbh' => $dbh ) ;

Then all the subsequent handlers need is : 

sub handler {

    my $dbh = $r->pnotes('dbh') ;	

}

To reuse the database handle. Very convenient.



-- 
http://litigios.libremen.com
Gestión de litigios y de expedientes de seguros de siniestros para el
servicio jurídico


Re: Singleton Persistence

Posted by John ORourke <jo...@o-rourke.org>.
I do it by treating the request as something transient - in other words
assuming that interpreter state is maintained between requests, and
resetting or recreating all the objects I use to process the request in my
fixup handler.

I make use of the persistence by having a singleton that maintains cached
data about the current virtual host to speed up request serving.

cheers
John



On 3 February 2014 21:44, John Dunlap <jo...@lariat.co> wrote:

> My current workaround is using this option in my apache configuration,
> PerlOptions +Parent
>
> to make sure that interpreters aren't shared between virtualhosts.
> However, this isn't good from a resource sharing perspective so it sounds
> like I may need to re-architect some of my code.
>
>
> On Mon, Feb 3, 2014 at 4:30 PM, Vincent Veyron <vv...@wanadoo.fr>wrote:
>
>> Le samedi 01 février 2014 à 20:14 -0500, John Dunlap a écrit :
>> > In mod_perl, can instantiated singletons survive requests? I'm asking
>> > because I appear to have one which *appears* to be bouncing back and
>> > forth between virtual hosts as perl interpreters are recycled. Is this
>> > possible and, if yes, how do I prevent it?
>> >
>>
>> Showing some code exhibiting the behaviour would help. You probably hit
>> something similar to this :
>>
>> http://perl.apache.org/docs/1.0/guide/porting.html#An_Easy_Break_in
>>
>> In any case, a singleton resides in the perl interpreter, which is used
>> by apache's child process to serve many requests, so it will survive
>> requests.
>>
>> You can do this however (I don't remember the exact parameter just now,
>> it's in the doc or the archives) :
>>
>> http://perl.apache.org/docs/2.0/user/design/design.html#Virtual_Hosts
>>
>> --
>> http://libremen.com
>> Gestión de litigios y de expedientes de seguros de siniestros para el
>> servicio jurídico
>>
>>
>

Re: Singleton Persistence

Posted by John Dunlap <jo...@lariat.co>.
My current workaround is using this option in my apache configuration,
PerlOptions +Parent

to make sure that interpreters aren't shared between virtualhosts. However,
this isn't good from a resource sharing perspective so it sounds like I may
need to re-architect some of my code.


On Mon, Feb 3, 2014 at 4:30 PM, Vincent Veyron <vv...@wanadoo.fr> wrote:

> Le samedi 01 février 2014 à 20:14 -0500, John Dunlap a écrit :
> > In mod_perl, can instantiated singletons survive requests? I'm asking
> > because I appear to have one which *appears* to be bouncing back and
> > forth between virtual hosts as perl interpreters are recycled. Is this
> > possible and, if yes, how do I prevent it?
> >
>
> Showing some code exhibiting the behaviour would help. You probably hit
> something similar to this :
>
> http://perl.apache.org/docs/1.0/guide/porting.html#An_Easy_Break_in
>
> In any case, a singleton resides in the perl interpreter, which is used
> by apache's child process to serve many requests, so it will survive
> requests.
>
> You can do this however (I don't remember the exact parameter just now,
> it's in the doc or the archives) :
>
> http://perl.apache.org/docs/2.0/user/design/design.html#Virtual_Hosts
>
> --
> http://libremen.com
> Gestión de litigios y de expedientes de seguros de siniestros para el
> servicio jurídico
>
>

Re: Singleton Persistence

Posted by Vincent Veyron <vv...@wanadoo.fr>.
Le samedi 01 février 2014 à 20:14 -0500, John Dunlap a écrit :
> In mod_perl, can instantiated singletons survive requests? I'm asking
> because I appear to have one which *appears* to be bouncing back and
> forth between virtual hosts as perl interpreters are recycled. Is this
> possible and, if yes, how do I prevent it?
> 

Showing some code exhibiting the behaviour would help. You probably hit
something similar to this :

http://perl.apache.org/docs/1.0/guide/porting.html#An_Easy_Break_in

In any case, a singleton resides in the perl interpreter, which is used
by apache's child process to serve many requests, so it will survive
requests.

You can do this however (I don't remember the exact parameter just now,
it's in the doc or the archives) :

http://perl.apache.org/docs/2.0/user/design/design.html#Virtual_Hosts

-- 
http://libremen.com
Gestión de litigios y de expedientes de seguros de siniestros para el
servicio jurídico