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
-------------------------------------------------------------

Attachment: dbi.patch
Description: Binary data

Attachment: ora.patch
Description: Binary data

Reply via email to