Re: sqlite3 dbd provider question

[William A. Rowe, Jr.]

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