apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: sqlite3 dbd provider question
Date Mon, 19 May 2008 23:31:02 GMT
Chris Darroch wrote:
> William A. Rowe, Jr. wrote:
> 
>>>  Are you referring to the Oracle dbd driver prepared-statement cache?
>>
>> yes; my question is, even if we do construct a cache, is module lifetime
>> appropriate?  When accessed by several different consumers at once?  
>> (e.g.
>> two libraries that rely on dbd, or several different httpd modules and
>> applications which consume dbd?).
> 
>   This cache code has always been disabled, IIRC.  The
> #define GLOBAL_PREPARED_STATEMENTS is commented out, I believe, and
> personally I've never tried un-commenting it.  I suspect that (as Nick
> Kew's comments indicate) it's not ready for use.

Then my thought is to remove the code entirely from apr branch 1.3.x and
encourage it's development and refinement on trunk.

The reason I've brought this all up is that I hope to transpose apr_dbd_lock
with an apr_module_lock, which would be used for all dynamic module loading.

But if we have excessive mutex contention, this will hurt us.

So I agree with you that the global logic can be gone, and we'll move
forward.  If you have such a patch to 1.3.x branch I'd be happy to simply
apply that (which lets me focus on apr_module api's for dbd and ldap at this
moment, and for dbm, iconv and xlate down the road).


Mime
View raw message