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
