No it was one of our DBAs who told us to take if off…! It causes them all sorts of problems – the main one being it keeps connections open, which is the best way to completely foobar the database servers! We make them happy by turning it off. We’ve even had Oracle developers (sorry not people developing SQL in oracle but people developing Oracle) scratching their heads over things like this and not being able to come up with a solution…..
We’ve discovered lots of interesting side effects with connection pooling when using over a secure network – e.g. the Oracle client doesn’t like running through a firewall – as it can’t cope when the firewall drops the connection – both sides of the system the “pool” thinks the connection is open, the database thinks the connection is open, and the client just hangs….. We have seen similar things with other applications which use connection pooling and long duration database handles. We get round it with permanent MySQL connections by closing/re-opening them after 5 minutes of inactivity – hence the need to develop our own cache/pool…. From: Mithun Bhattacharya <mit...@gmail.com> Sent: 07 February 2021 20:36 To: James Smith <j...@sanger.ac.uk> Cc: Vincent Veyron <vv.li...@wanadoo.fr>; Steven Haigh <net...@crc.id.au>; modperl@perl.apache.org Subject: Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT] DBI sharing has it's own issues but in most use cases it does a pretty good job and keeps the DBA's happy - that is very important ;) On Sun, Feb 7, 2021 at 2:23 PM James Smith <j...@sanger.ac.uk<mailto:j...@sanger.ac.uk>> wrote: DBI sharing doesn't really gain you much - and can actually lead you into a whole world of pain. It isn't actually worth turning it on at all. We use dedicated DB caching in the cases where we benefit from it as and when you need it (low level caching database)... Although milage may vary - our problem was DB servers with 30 or 40 databases on them being connected from a number of approximately 50-100 child apaches, meant we ended up blowing up the connections to the database server really quickly... -----Original Message----- From: Vincent Veyron <vv.li...@wanadoo.fr<mailto:vv.li...@wanadoo.fr>> Sent: 07 February 2021 19:06 To: Steven Haigh <net...@crc.id.au<mailto:net...@crc.id.au>> Cc: James Smith <j...@sanger.ac.uk<mailto:j...@sanger.ac.uk>>; modperl@perl.apache.org<mailto:modperl@perl.apache.org> Subject: Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT] On Sun, 07 Feb 2021 23:58:17 +1100 Steven Haigh <net...@crc.id.au<mailto:net...@crc.id.au>> wrote: > > I haven't gotten into the preload or DBI sharing yet - as that'll end > up needing a bit of a rewrite of code to take advantage of. I'd be > open to suggestions here from those who have done it in the past to > save me going down some dead ends :D I use mod_perl handlers, so not sure how it mixes with PerlRegistry, but you probably want to have a look at connect_cached -- Bien à vous, Vincent Veyron https://urldefense.proofpoint.com/v2/url?u=https-3A__compta.libremen.com&d=DwIFAw&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4oDX0XM7vQ&m=C0OcuGbNbfxaSa8ASgV3uFXzejn7MpjIUH1aP1RbiyU&s=GPr8VuKQ3rZCzCPwggyAHdCOojK6ZThmShKk0Jb3maI&e= Logiciel libre de comptabilité générale en partie double -- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
