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. > 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. 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. > 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. You're probably best placed to judge how to use them for mod_perl. > 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 :) Tim.
