[Catalyst] How to share a database connection across multiple Catalyst apps?

[Brian Phillips]

(Hopefully I'm not out of my depth here)

I feel your pain WRT Oracle connections as we've had similar complaints from
our DBA overlords about the number of connections our app was making here at
$work.  Do you have your mod_perl processes behind some sort of proxy?  If
you run your mod_perl application in the same apache instance that serves
static content any child that is spawned, even if it's just for serving HTML
or an image file, will be fully functional (including having a database
connection for each catalyst app that is hosted on that server).  You might
consider changing how your application is deployed and use FastCGI (or
mod_perl behind a proxy) so that it's easier to control the number of
processes (and therefore database connections) you spin up.

On Wed, Sep 8, 2010 at 10:46 AM, Stuart Watt <swatt at infobal.com> wrote:

>  Sounds like a job for DBD::Proxy or DBD::Gofer, not that I've ever used
> them, and I have no idea whether they would play nice with DBIC -- the DB=
IC
> folks would have a better grasp on that question. That would leave the
> Catalyst parts unchanged apart from configuration, which would be a good
> thing architecturally.
>
> --S
>
> Stuart Watt
> ARM Product Developer
> Information Balance
>
> On 9/8/2010 10:54 AM, Simon Miner wrote:
>
> Thanks for the responses,
>
> Jason, I don't think reducing the number of database connections will hurt
> responsiveness.  Even though there are 3 separate Catalyst apps, each HTTP
> request will only involve one of them (since they all run out of the same
> web server), so there should never be contention between the apps for the
> shared database connection.  Does this make sense?
>
> Tom and Nicholas, I wish this was premature optimization, but my
> organization has experienced serious performance issues in the past relat=
ed
> to multiple (Oracle) database connections per HTTP server process.  Extra
> Oracle connections are expensive to maintain, particularly on the database
> server, and so we've tried to ensure that a single server process only ha=
s a
> single connection to a given database (since that's all it should need at
> any given time).
>
> I've attached a Devel::NYTProf screenshot for one of the server processes=
 I
> profiled this morning. Looks like it confirms the multiple database
> connections.
>
> So back to initial question -- How do I update the models of my three
> Catalyst apps to share a single Oracle database connection?
>
> Thanks again.  I really appreciate your feedback.
>
>  Simon
>
> On Tue, Sep 7, 2010 at 11:40 PM, Nicholas Wehr <
> catalyst at bionikchickens.com> wrote:
>
>> I'm with Tom on this one. Unless you've narrowed all optimization efforts
>> and this is all you have left - it could be worth a try.. but as Jason
>> points out, you may not gain a thing. I'd recommend profiling your code =
and
>> tracking down performance issues from that base level. Please post your
>> results - I've very curious!
>>
>> -nw
>>
>>
>> On Tue, Sep 7, 2010 at 7:21 PM, Tomas Doran <bobtfish at bobtfish.net>wrote:
>>
>>>
>>> On 7 Sep 2010, at 18:59, Simon Miner wrote:
>>>
>>>> All three of these apps run under a single Apache 1.3.42/mod_perl 1.31
>>>> server.
>>>>
>>>
>>>  Wow, mod_perl 1.... Ok then :)
>>>
>>>
>>>   It appears that each server process creates a unique database
>>>> connection variable for each of these apps. Although these database
>>>> connections get reused from request to request, I would like to make t=
hings
>>>> even more efficient by having a single database connection variable per
>>>> server process which gets shared across all 3 Catalyst apps.
>>>>
>>>
>>>  Why do you think that this will help or affect anything?
>>>
>>> I.e. is this not premature optimisation?
>>>
>>> Cheers
>>> t0m
>>>
>>>
>>>
>>> _______________________________________________
>>> List: Catalyst at lists.scsys.co.uk
>>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>>> Searchable archive:
>>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>>> Dev site: http://dev.catalyst.perl.org/
>>>
>>
>>
>> _______________________________________________
>> List: Catalyst at lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive:
>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>>
>
>
> --
> -- Simon
>
> --
> This message was scanned by ESVA and is believed to be clean.
> Click here to report this message as spam.<http://antispam.infobal.com/cg=
i-bin/learn-msg.cgi?id=3D7897728072.B3B1D>
>
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.u=
k/
> Dev site: http://dev.catalyst.perl.org/
>
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100908/07377=
92d/attachment.htm