Re: TIPool / multiple database connections

[Gerald Richter <ri...@ecos.de>]

Hi,

I am a little late for the thread, nevertheless I like to give experiences I
gathered trying to get DBI threadafe. As Stas already said before in this
thread I have made a patch to DBI which makes DBI threadsafe. The result is
released in DBI 1.30. This doesn't mean that the DBD driver can handles
this, but mostly it's not hard to add.

Threadsafe means not that you can share any sort of DBI handles. It's means
that it's safe to use DBI with threads and that it is made sure that every
intances of the Perl interpreter (i.e. every thread) gets it own instance of
DBI.

My inital goal was to share DBI handles between threads, but this would need
very much work inside DBI. Additionaly Perl does not yet support sharing of
objects (BTW share does not deep share data structures). So Tim suggested to
first make DBI work correctly with threads at all. That's what we have done.

Gerald

P.S. I have some experimental code to share database handles inside of
DBD::Oracle, since this was much easier to implement, but this is not quite
ready yet.


-------------------------------------------------------------
Gerald Richter    ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:       Tulpenstrasse 5         D-55276 Dienheim b. Mainz
E-Mail:     richter@ecos.de         Voice:    +49 6133 925131
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------


----- Original Message -----
From: "Elizabeth Mattijsen" <li...@dijkmat.nl>
To: "Stas Bekman" <st...@stason.org>; "Perrin Harkins" <pe...@elem.com>
Cc: "Tim Keefer" <tk...@allenpress.com>; <mo...@perl.apache.org>
Sent: Tuesday, July 16, 2002 11:17 AM
Subject: Re: TIPool / multiple database connections


> At 02:57 PM 7/16/02 +0000, Stas Bekman wrote:
> >Perrin Harkins wrote:
> >>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?
> >That's what I meant. Probably non need for Thread::Pool, at all. use a
> >shared datastructure, maintain a list of free and busy items and simply
> >hand pointers inside this datastructure to the threads asking for an
item.
> >e.g.:
> >
> >package DBI::Pool;
> >use threads::shared;
> >my @pool : shared;
> >sub init {} # pre-populate pool with N connections
> >sub get {}  # return a ref to $dbh, grow the pool if needed
> >sub put {}  # move the pointer from the busy list to the free list
>
> Hmmm... as long as you do this _before_ the (Apache) threads get started,
> this might work.  I still haven't got my mind entirely around what one is
> allowed to do, what you can do and is allowed, what you can't do but is
> allowed and crashes, and what in principle is possible but you're barred
> from because of e.g. prototyping getting in the way.
>
>
> >won't this work? I guess Perrin is right in respect that the whole item
> >needs to be shared (deep-shared). can we have such an attribute/function
> >that will automatically traverse the datastructure and share it all? or
is
> >this the case already with 'shared'?
>
> Good question.  I don't think it is deep shared and that's why it probably
> doesn't work.  The way Thread::Queue::Any (which is the transport medium
> for Thread::Pool) handles this, is by serializing any data structure with
> Storable, pass that around and deserialize that on the other end.
>
>
> >Now since we want to have various connections, it can be:
> >my %pools : shared;
> >where each key is a unique identifier, "compiled" from the dbi connect's
> >DSN string and a value is the actual pool.
>
> That's an approach.  If you could actually share the $sth objects.  About
> which I have my doubts.
>
>
> >BTW, there is no more need for Apache prefix in Apache::DBI, this can be
a
> >generic Pool class. I guess Apache::DBI can subclass DBI::Pool and add
> >things like connect_on_init(), but just to build the initial pool when
the
> >process starts.
>
> DBI::Pool would be ok.  But unless I'm wrong about the sharing issues,
> you're going to be stuck, at least with this version of Perl, with
> serializing between threads.
>
>
> Liz
>
>