On Sat, Mar 08, 2003 at 11:45:04AM +1100, Stas Bekman wrote:
Tim Bunce wrote:
p.s. I'm hoping DBI 1.35, which I've just released, will be fairly stable and I can aim to put new things like this, and 'take_imp_data' for Stas, into development releases leading up to a DBI 1.36.
So how do we proceed from here? Should we take something like DBD::myqsl and work out the API on it? And then try some other package?
Most of the changes are in the DBI so I'll start there and work outwards and see what I end up with.
Great!
we also need to spec out how to maintain more than one pool (1 pool per 1 dsn).
Per dsn, plus at least $user & $password.
Ah, yes, of course.
There is an issue of changes to the server-side state between getting and returning a connection to the pool. An obvious example being AutoCommit, but there are pleanty of others. It probably just boils down to applications needing to be 'well behaved'. But it might be worth including the \%attr in the pool hash, just the way Apache::DBI currently does.
Yes. I see the pooling to be modeled after Apache::DBI, but instead of storing the whole $dbh, we will just store parts of it.
One more thing I was thinking about is that drivers should be able to declare whether they support pooling and for users to be able to tell that they want pooling. Only if the two match, then the pooling should be used.
Also it'd be nice if the user side could be done similar to Apache::DBI so users don't need to change their code, but just load some module on or off. However it'd be nicer to have a more fine tuned control, rather than just it's on or off. Any good ideas? I was thinking along the lines of Perl magical variables, so you can turn them on everywhere, but be able to turn things off in some local scope.
I was thinking that using some sort of hash list will do (hashing on dsn and then having a linked list on each entry.) As Philippe has pointed out mod_perl 2.0's modperl_tipool.[hc] can be re-used. (tipool = Thread Interpreter Pool)
I think I can leave that pretty much in your hands. The basic mechanisms that the DBI will provide are not themselves related to threads.
That's correct. It should work the same w/ and w/o threads.
Finally, there is a bug with threads.pm which we may have problems with under natively threaded apps, like mod_perl:
http://archive.develooper.com/[EMAIL PROTECTED]/msg00649.html
I'm no expert on iThreads, but it seems like mod_perl needs to hook into apache so that when apache spawns a new thread perl can also clone an interpreter read for that thread to use. But I could easily be very wrong :)
First of all, threads.pm and mod_perl perl interpreter pool have little to do with each other, other than using perl_clone(). Normally you don't need to boot threads.pm to work with mod_perl 2.0 (w/ threaded mpm).
Under mod_perl 2.0. There can be 1 Perl interpreter and 10000 OS threads. There can be 100 interpreters and 10 OS threads. They don't need to map 1:1. So the process of Apache's spawning OS threads and the process of Perl cloning interpreters are not related.
I needed to use threads.pm only for mutex locking. So we can have a thread-safe pool management. However while things work fine in a standalone app (with ithreads) it seems that we are having a problem in threaded apps (like Apache). Since all we need is to provide locking, we may end up ripping the locking code from threads.xs and have it working differently under mod_perl. Of course it'd be cool for threads.xs to be fixed, but this seems to be a design issue, so I won't bet for it being fixed any time soon. And it doesn't matter much since it's broken in the core perl 5.8, not CPAN module, which can be upgraded.
Perhaps we can have the pool management implemented in a separate module, so DBI won't have to be dependent on this kind of situations.
__________________________________________________________________ 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
