Return-Path: X-Original-To: apmail-perl-modperl-archive@www.apache.org Delivered-To: apmail-perl-modperl-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3EB4210D46 for ; Thu, 27 Feb 2014 17:46:29 +0000 (UTC) Received: (qmail 45879 invoked by uid 500); 27 Feb 2014 17:46:28 -0000 Delivered-To: apmail-perl-modperl-archive@perl.apache.org Received: (qmail 45797 invoked by uid 500); 27 Feb 2014 17:46:27 -0000 Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list modperl@perl.apache.org Received: (qmail 45790 invoked by uid 99); 27 Feb 2014 17:46:27 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Feb 2014 17:46:27 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.192.171] (HELO mail-pd0-f171.google.com) (209.85.192.171) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Feb 2014 17:46:23 +0000 Received: by mail-pd0-f171.google.com with SMTP id r10so2708674pdi.16 for ; Thu, 27 Feb 2014 09:46:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fRvycMCPCP/aM++4oUBKqs4fvpTSiSE0OOAZCp2lCEM=; b=h3ekEMG0xqq61pzSFRYm/sQsoulFt3/7prVjzbT0GVBKPWqKRxNYpqeRCfkzuaWGG3 Z/C7kUCx1WWqJ/nh6qZ3aBEbhEfXNdVI+aE897igaA7rOyGMnHVIjPG5voPnp2Ebo+P7 t9hHQ8GawTcZoVUXqS+HCEdY6fawrxFM3yfQeo30tL8HyIxMFblwda2ibmAP7+mDXAMq lyGBzEnYs3CjH4vLuKjtiQ4KOwueHwuh6Ba/8AVPGhNLcmyOmDV/q6tDO8dFs5KiAvBv JWK+BVHDwy/1G76IElZ8INUDwYQo2e6Cb99Ckyfh5hovw8TAjC7YFuoCjD33Be3DXw6R DC3g== X-Gm-Message-State: ALoCoQmYCcI8PC/4KJuB0LcDimE30zdTyIFNuNvLIzr+It0Uy55s2n0cx5p918UNbap4czQcTDuT MIME-Version: 1.0 X-Received: by 10.68.204.231 with SMTP id lb7mr14646587pbc.30.1393523162936; Thu, 27 Feb 2014 09:46:02 -0800 (PST) Received: by 10.70.3.133 with HTTP; Thu, 27 Feb 2014 09:46:02 -0800 (PST) In-Reply-To: References: Date: Thu, 27 Feb 2014 12:46:02 -0500 Message-ID: Subject: Re: Singleton Persistence From: John Dunlap To: Rolf Schaufelberger Cc: mod_perl list Content-Type: multipart/alternative; boundary=047d7b2e474e1d0e9c04f366e5cf X-Virus-Checked: Checked by ClamAV on apache.org --047d7b2e474e1d0e9c04f366e5cf Content-Type: text/plain; charset=ISO-8859-1 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 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 : > > > 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 > --047d7b2e474e1d0e9c04f366e5cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In the solution that I ended up using, the singleton in qu= estion contains the reference to IOC::Container, which contains service lit= erals for each of the constants which are available in $apache->dir_conf= ig. As a performance enhancement, when I attempt to retrieve an object from= the container, I check the server hostname against the hostname in the con= tainer and only reinitialize the container if they don't match. This av= oids reinitializing the container if it happens to be sequentially used in = the same virtualhost multiple times. I suppose I could have built a more so= phisticated caching system which stores container instances in a hash and r= etrieves the correct one by hostname but I didn't feel like spending th= e time and it seemed like a more fragile approach than I'm comfortable = with.

if (is_isa($apa= che, 'Apache2::RequestRec')) {
my $server_hostname =3D $apache->server->se= rver_hostname;
my $container_host= name =3D $container->get('hostname');
if ($server_hostname ne $container_host= name) {
$container->{C= } =3D undef;
$container->_init_components($apache);
}
}



On T= hu, Feb 27, 2014 at 12:34 PM, Rolf Schaufelberger <rs@plusw.de> wr= ote:
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"}=3D u= ndef;
    }
    $self->{appl}=3D PW::Application->instance($param{base}= );

I tried Apache::Singleton before, but, as far as I can remember,  it d= idn’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 &= nbsp;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 single= ton with every request works for me .



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

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


Rolf Schaufelber= ger

--047d7b2e474e1d0e9c04f366e5cf--