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

[Brandon Black]

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