Re: Singleton Persistence

John ORourke <[email protected]>
Newsgroups gmane.comp.apache.mod-perl
Message-ID <CANEV0tu9k6nPk2uxRWY-8x5VKBHdtDKP5n+7SwyaGAcBm3V97Q@mail.gmail.com>
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 <[email protected]> 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 <[email protected]>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
>>
>>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.