I guess the DBA's don't like it because Oracle starts one process per
connection unless you use connection pooling.
I think that's a listener setting, your DBA's should know.
--
Best regards, Alex
Am Mittwoch, den 08.09.2010, 16:54 +0200 schrieb Simon Miner:
Thanks for the responses,
Jason,
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
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 DBIC folks would have a better grasp on that question. That would
leave the Catalyst parts unchanged apart from configuration, which would
be a good
(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
On 8 Sep 2010, at 19:17, Javier Arturo Rodriguez wrote:
On 9/8/10 4:54 PM, Simon Miner wrote:
The parameters defining the connection have to be exactly the same,
including the connect attributes! If there is no appropriate
database handle or if the ping method fails, a new connection
Hi,
I am running 3 separate Catalyst (version '5.80022) apps that use a common
(Oracle 11g) database. Each app has a model class which wraps around a
common DBIC schema class, like so.
-
package App1::Model::DB;
use strict;
use base 'Catalyst::Model::DBIC::Schema';
Hi Simon,
Reducing the number of connections to the database from three to one
will reduce the responsiveness and will definitely hurt when trying to
debug issues (performance, etc). My recommendation is that each
application have at least one unique connection to the database.
jason
On
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
