[Dbix-class] Re: [Catalyst] Testcase for DBIx::Class::Loader - demonstrates failure under load

[Brandon Black]

On 2/13/06, Brandon Black <blblack at gmail.com> wrote:
> On 2/13/06, Toby Corkindale <tjc at wintrmute.net> wrote:
> > On Mon, Feb 13, 2006 at 09:55:31AM -0600, Brandon Black wrote:
> > > Note that for DBIC/DBIC::Loader under Catalyst, I don't believe you need
> > > Apache::DBI for persistent connections.  I believe as long as the model
> > > instance stays alive, the connection is persistent anyways without it.  I
> > > could be wrong, but I don't think so.
> >
> > Ah, cool. Yes, that appears to be the case.
> >
> > I wonder how that effects rollbacks at the end of processing (with and without
> > Apache::DBI).
> > I'll have to test that out sometime.
> >
>
> It should have no ill effects for the "normal" DBIC case (like
> C::M::DBIC::Plain / C::M::DBIC::Schema), the only ill effects will be
> under DBIC ::Loader and ::Schema::Loader.  DBIC itself does
> rollback-on-disconnect itself before calling the DBI disconnect
> method, and it does this anytime the storage is being DESTROYed
> (Apache::DBI kinda nullifies the actual disconnect, but the process is
> dying anyways, so no biggie).
>
> The big ugly issue in this for the Loaders is that DBI.pm actually
> looks for the presence of Apache/DBI.pm in %INC, and if so it sets a
> *class* (or package if you prefer) variable $DBI::connect_via to
> redirect its own connect/disconnect stuff through Apache::DBI.  The
> whole DBI + Apache::DBI model of interaction is kinda flaky
> considering the multiple apps under one mod_perl scenario.
>
> The cleanest answer is probably to, in your mod_perl configuration,
> preload the Catalyst application module before you preload
> Apache::DBI.  But we should probably handle the situation regardless
> of load order.
>
> I've made the testcase work against Apache::DBI locally here, by
> effectively storing up the old $DBI::connect_via, and overriding it
> back to the "normal" DBI setting while Loader is doing its setup, then
> restoring it after we're done.  I've thought through the implications
> for other hypothetical Apache::DBI-using code sharing the same
> mod_perl, and I don't think this is capable of causing them problems,
> but I need to think some more before committing that.
>
> -- Brandon
>



Thought I'd move this over to the DBIC list. [ Toby are you on this
list as well? ]

Come to think of it, the (relatively new) automatic column_info stuff
may indeed make a non-Loader DBIx::Class::Schema exhibit these same
Apache::DBI issues under some scenarios.  It tries to use storage back
at ->add_columns time.  This should fail in the case that the given
schema has no connection information (hence it being wrapped in an
eval I think), but I suspect there's going to be some cases where this
triggers the same issue if the connect info is defined one way or
another before mod_perl forks off.

Should DBIx::Class itself perhaps also wrap dbh->disconnect /
DBI->connect in Storage/DBI.pm similarly (check for Apache::DBI, and
if so store off the old $DBI::connect_via during the operation, then
restore it right after?).  If we end up doing it there, the fix for
loader can just use that too (need to convert the vendor classes to
use storage anyways, instead of their current manual DBI->connect()
statements).

-- Brandon