Hi, > You have a good chance to get something later today
I did had some other work to do over the weekend, but now we start the week with a new patch :-) > The old perl5005 threading model is badly flawed and dangerous. > The DBI shouldn't support it now there's something better. > It's dead - rip it out! Anyone still needing it can stick with DBI 1.28. > I have deleted what I have found, maybe I missed something. > Can you change the message to be more like: > > "%s %s failed: handle %s is owned by thread %x not current thread %x (handles can't be shared between threads and your driver may need a CLONE method added)" > done > Another issue.... currently CLONE ends up just calling dbi_bootinit. > I think that's too much and it needs some custom code (call it dbi_cloneinit :) > that just does something like: > - aloc a new DBIS but then copy over the contents of the 'old' one > - just change elements of if that are interpreter specific: > DBIS->neatsvpvlen - just get_sv to get new pointer, don't sv_setiv > g_dbi_last_h & DBI_UNSET_LAST_HANDLE - also keeps DBI::var::FETCH safe > That should be enough. And doing just that means that things like > trace level and $DBI::neat_maxlen will be properly 'cloned'. > Mmmh... I have used dbi_bootinit and not created dbi_cloneinit not only due to my lazyness, but because I wanted to make sure we get a proberly initialzed dbistate structure. Most of the initialization has to be done per thread. The only thing we can save, is the setup of the callbacks, but it doesn't make a difference if we copy them from the old dbistate structure or initialize them. To get the value of the parent for debuging, I now pass the parent dbistate and copy the few values that needs to carried over. This seems more save to me. The dbi.patch is against DBI 1.28 Also attached is the patch for DBD::Oracle that keeps the globals (like ora_long etc.) in the driver handle to make them threads safe. (I also replaced fprintf with PerlIO_printf, to reduce the number of warnings) And (and that's the real reason why it didn't was ready on friday) I have implemented your idea of sharing Oracle database connections in DBD::Oracle. The usage is: our $orashr : shared = '' ; $dbh = DBI -> connect ($dsn, 'scott', 'tiger', {ora_dbh_share => \$orashr}) ; the first connect will make the connection, all following calls to connect with the same ora_dbh_share parameter will use the same database connection. I do some internal ref counting to make sure the connection is closed when the last $dbh is destroyed. I share the server and the svcctx handle, while the error handle is still per thread. Also the environment handle is per thread. This is what seems to make sense for me, after trying to understand how OCI works (never have doen OCI programming before). I have added a few sentence about this to the docs, but I guess have to convert them to correct english :-) The Oracle patch is againt DBD::Oracle 1.12 Gerald P.S. There are two performance issuses with threads in DBI (just in case you not already aware of them): It would be better to pass the pointer to the Perl interpreter to every function i.e. use the pTHX_ as first parameter. At the moment it's taken out of the Perl thread local storage everytime it's needed i.e. for every call into Perl. This issuse also touchs the DBD drivers, but mainly it's a lot of copy & paste work. Access to the dbistate structure (the DBIS macro) is very inefficient when using threads. It involves at least one hash lookup and SV -> PTR conversion. The macro is used very often. It would be better to use it only once per function and store the dbistate pointer in a local variable, even better pass it as an extra parameter. At the moment it would also be possible to pass it inside of the handle, but I wouldn't do this, so we are able in the long run to share DBI handles between threads. I don't have the time to work on either of them (sorry), just wanted to mention it, so it will be get done sometime in the future. ------------------------------------------------------------- Gerald Richter ecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925131 WWW: http://www.ecos.de Fax: +49 6133 925152 -------------------------------------------------------------
dbi.patch
Description: Binary data
ora.patch
Description: Binary data