schweini has asked for the wisdom of the Perl Monks concerning the following question:

hey! ho!

i finally found a question that i didn't find the answer to here - so here goes:

anybody know how to do a DBI "multicast"? i.e.: connect a $dbh to two different servers at the same time, and getting all requests to be sent to both simultanously?
(obviously for redundandcy reasons)
DBI::proxy or multiplex (whatever THAT exactly is) can't seem to help.

anybody?

schweini

Replies are listed 'Best First'.
Re: DBI multicasting?
by rob_au (Abbot) on Nov 19, 2001 at 04:35 UTC
    As far as I know, this is not supported behaviour within DBI or any existing module which supports DBI - Nevertheless, it would not be particularly difficult to create such a module which when called would create its only individual DBI handles to the respective database servers and when passed a execution request, forwarded it onto each DBI handle.

    Update - Have a look at DBD::Multiplex as pointed out by lhoward in the post below

     

    Ooohhh, Rob no beer function well without!

[reply]
Re: DBI multicasting?
by ask (Pilgrim) on Nov 19, 2001 at 07:33 UTC
    If it's just for redundancy (and load balancing), you could make a wrapper for the DBI module that upon a database failure will try to replay to transaction on the other server. If it's only for reading it shouldn't be too hard.

     - ask 

    -- 
ask bjoern hansen, http://ask.netcetera.dk/   !try; do();
[reply]
      Agreed, this should be fine for the extraction of data - But if the client is looking submitting or changing data to the databases, then the best method would be for the wrapper to have two (or more) concurrent DBI handles with DBI->autocommit disabled. The DBI->commit method could be called after execute statements to all database handles had been issued. While this method isn't as good as internal synchronisation at the database level, it should suffice for most circumstances.

       

      Ooohhh, Rob no beer function well without!

[reply]
[d/l]
[select]
        So what do you do if the commit fails on the second database handle?

        In any case it's hard to give advice on something like this without knowing more details about what kind of application the system needs to support.

         - ask 

        -- 
ask bjoern hansen, http://ask.netcetera.dk/   !try; do();
[reply]
Re: DBI multicasting?
by lhoward (Vicar) on Nov 19, 2001 at 17:39 UTC
    This is one of the things that DBD::Multiplex is written for. I've been interested in trying out DBI::Multiplex for a while, but its lack of documentation or examples had made it a frustrating and fruitless exploit. About the only halfway decent thing I've found on it is here. The package itself also doesn't seem to have changed since July of 1999 (it comes bundled with DBI).
[reply]
Re: DBI multicasting?
by lachoy (Parson) on Nov 19, 2001 at 18:31 UTC

    Mostly ontopic: SPOPS could be fairly easily modified to give you this sort of functionality. I already created a very similar module for the LDAP interface (SPOPS::LDAP::MultiDatasource) and doing it for DBI would be relatively simple. As lhoward brought up, one of the issues is what to do if the second (or third, or...) INSERT/UPDATE/DELETE fails. But we've already got a crude-but-improving framework for that.

    Now that I think about it, I'm going to put this on the feature request list. Being able to publish or select information from different databases (even databases from different vendors, on different hosts) would be pretty cool.

    Chris
    M-x auto-bs-mode

[reply]

Back to Seekers of Perl Wisdom