Can somebody help me knowing how to unsubscribe from this mailing list? Praveen
-----Original Message----- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 27, 2005 2:48 PM To: Dean Arnold Cc: DBI-dev Subject: Re: DBIx::Threaded feedback Dean Arnold wrote: > Stas Bekman wrote: > >> Dean Arnold wrote: >> >>> I'd appreciate any reviews of my current >>> DBIx::Threaded design as outlined at >>> http://www.presicient.com/dbixthrd >>> >>> I've already implemented most of it, and have begun >>> testing, but I'd like a bit more feedback before >>> I rollout RC1. If you see something thats broken, >>> or if something is missing, please let me know. >> >> >> >> Dean, check the discussion on take_imp_data and DBI::Pool[1] in this >> list's archives. >> >> [1] http://stason.org/tmp/DBI-Pool-0.02.tar.gz >> >> You can't really use Storable to snatch the underlaying datastructs >> from a random DBD. Tim has started working on take_imp_data and >> DBD::mysql is the first one to have a support for it. But there are >> issues with it and I was waiting for Tim to fix those in DBI before >> moving on with DBI::Pool. >> >> The advantage of DBI::Pool is that it'll work transparently for the >> users (like Apache::DBI does), and require no special coding. >> > > Doesn't it require special coding in the DBDs ? (i.e., each driver > has to implement take_imp_data() and possibly other stuff ?) > > Will it permit the DBI-derived objects to be passed between threads > (i.e., will it automagically marshal/unmarshal the objects into > something that can be passed, e.g., on a queue) ? (General, Perl case, > not Apache-specific) There is nothing specific to Apache in it. I was just using Apache::DBI as an example of how to make things transparently. > DBIx::Threaded requires *no* changes to any DBDs or the DBI (at least, > it hasn't thus far). > > It also doesn't require any changes to apps, other than to use > > use DBIx::Threaded; > > $dbh = DBIx::Threaded->connect(...); > > ...and maybe observe some of the other limitations (most of > which appear to be very minor corner cases). I spose if an > app gets clever about "ref $sth" looking for DBI::st, and > gets DBIx::Threaded::st instead, it might break...but thats > a general subclass issue. > > DBIx::Threaded derived objects are automagically marshalled/unmarshalled > (assuming the app uses Thread::Queue::Duplex to pass things around), > due to the apartment threading model used (apps just get thin > veneer client objects, all the real work goes on inside the apartment > thread) > > I realize that DBI::Pool solves some problems, but it appears to rely > on DBD authors to make some changes; unfortunately, I have an immediate > need, and can't rely on that....unless I missed something ? Tim has followed up on those issues. I'd only add that doing changes in DBDs is easy, since it's done once - changing millions of programs is not. > OTOH, I'd certainly like DBIx::Threaded to play nice w/ Apache, but > I'm not certain what/how/when to do about that. Dean, you are more then welcome to take over DBI::Pool development. I don't use DBI at the moment, so it'd make much more sense for someone else to lead the development (it's not on CPAN, so you can choose another name for it). I'm sure that both your ideas and ours can be integrated into one great module. -- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments.
