Elizabeth Mattijsen wrote: > 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)
Hmmm... That could really throw a wrench in things. If you have an object based on a hash, and you share that hash, and you re-bless the object in each thread, does that work? What if the hash contains references to other variables. Do they need to be explicity shared as well? > 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). It could be useful for people who design their applications to use different database logins for each end user. This would allow the server to maintain a single persistent connection to the database for that user, rather than one in each process. > Or you could have 10 worker threads with 40 threads submitting jobs. > That would work faster if your database is threaded as well ;-) That would work well for the more common case, once the DBI threading issues are worked out. But does this mean we would need to create a whole new interface for sending in queries and getting results back, because the actual $sth objects can't be shared? That would be painful. Maybe some kind of local proxy object could handle this, forwarding all method calls to the worker thread and returning all results. It would be kind of like a transparent RPC mechanism. - Perrin
