FAQ

On 2/13/06, Brandon Black wrote:
On 2/13/06, Toby Corkindale 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

Search Discussions

  • Toby Corkindale at Feb 13, 2006 at 6:10 pm

    On Mon, Feb 13, 2006 at 11:09:49AM -0600, Brandon Black wrote:
    On 2/13/06, Brandon Black wrote:
    On 2/13/06, Toby Corkindale 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? ]
    I am now :)

    --
    Turning and turning in the widening gyre/The falcon cannot hear the falconer;
    Things fall apart, the centre cannot hold/Mere anarchy is loosed upon the world
    (gpg --keyserver www.co.uk.pgp.net --recv-key B1CCF88E)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbix-class @
categoriesperl, catalyst
postedFeb 13, '06 at 6:02p
activeFeb 13, '06 at 6:10p
posts2
users2
websitedbix-class.org
irc#dbix-class

2 users in discussion

Brandon Black: 1 post Toby Corkindale: 1 post

People

Translate

site design / logo © 2021 Grokbase