At 01:14 AM 7/16/02 +0000, Stas Bekman wrote:
>>Hmmm... I guess you're right. I hadn't thought of applying Thread::Pool
>>in this situation, but it sure makes sense. This would however imply
>>that jobs would be submitted from different threads. That _should_ work,
>>but I just realised that I don't have a test-case for that. Will work on
>>one and let you know the result.
>I think that's a reverse case, the pool creates the dbh items (tools) and
>workers pick the items use them and then put back when they are done with
>them. So it's the pool who creates the "things".
Hmm... but you won't be able to "fetch" the $dbh from the thread. It can
only live in _that_ thread. You cannot "pass" objects between
threads. But you _can_ send queries to that thread, fetch a jobid for that
job and then obtain whatever was returned as a Perl datastructure.
(if anyone knows of a way to pass objects between threads, I'd really would
like to know)
With Thread::Pool you would do something like this:
use Thread::Pool;
my $pool = Thread::Pool->new(
{
workers => 10,
pre => \&pre,
do = \&do,
},
database parameters );
@result = $pool->wait( query parameters );
sub pre {
my $dbh = (make database connection with @_);
# maybe "prepare" any statements
return $dbh;
}
sub do {
my $pool = shift;
my ($dbh) = $pool->pre;
# do whatever you want to do in the database, dependent on @_
# could be any standard list, data-structure, etc, but _not_ an object!
return @result;
}
>btw, one thread should be able to pick more than one item at once. but in
>this particular case of DBI, I think there should be a different pool for
>each connectin group. similar to what Doug has suggested in his original
>TIPool prototype in the overview doc.
Thread::Pool doesn't work that way. You could have 1 database connection
in one worker thread and 40 threads submitting jobs: they would be handled
in the order they were submitted. This effectively serializes access
(which could be an approach for DBI drivers that do not support _any_
threading at all).
Or you could have 10 worker threads with 40 threads submitting jobs. That
would work faster if your database is threaded as well ;-)
Liz
