On Jun 27, 2011, at 12:53 PM, Octavian Rasnita wrote: > DBIx::Class already manages its connections for you, and therefore it > cannot benefit from Apache::DBI under any scenario. It makes one > connection per-process, and keeps that connection persistent, > reconnecting only if the connection appears to have died, or if you > fork/thread over to another process/thread-id. The only Apache::DBI > issue in DBIx::Class is that Apache::DBI will actually thwart > DBIx::Class's connection management code, and cause it to use the same > (and invalid) connection in a new process, in cases such as (as > mentioned above) if you make a DBI connection before forking in a > prefork mod_perl server. > > To work around this, DBIx::Class has specific code in it to work > around Apache::DBI, nullifying the effects of Apache::DBI on > DBIx::Class. Essentially, loading Apache::DBI should change nothing > and be rather pointless under DBIx::Class. > > The only reason we support it (support working around it) is because > someone might want Apache::DBI loaded up under the same mod_perl as a > DBIx::Class application to support a different legacy application > which does not use DBIx::Class, in which case they share a perl > interpreter and will both have the same set of modules loaded.
The same statements apply to DBIx::Connector, FWIW. Best, David
