Fwd: svn commit: r593283 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c

[Eric Covener <co...@gmail.com>]

Any thoughts on how to contrast uldap_connection_close() vs
uldap_connection_cleanup()?

uldap_connection_close() tears down the minimal amount, leaving a
bound connection floating around, but the doc talks about tearing the
entire connection down. uldap_connection_cleanup() documents pretty
much the same behavior.

Since close() and cleanup() seem so close to eachother, should we make
them do the same thing and add some operation that's more clearly
unlocking/releasing the pooled connection?

(authnz_ldap's r->pool cleanup would call unlock()/release() pretty
much exclusively)

-- 
Eric Covener
covener@gmail.com

Re: Fwd: svn commit: r593283 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c

[Brad Nicholes <BN...@novell.com>]

>>> On 11/8/2007 at 1:10 PM, in message
<14...@mail.gmail.com>, "Eric Covener"
<co...@gmail.com> wrote:
> Any thoughts on how to contrast uldap_connection_close() vs
> uldap_connection_cleanup()?
> 
> uldap_connection_close() tears down the minimal amount, leaving a
> bound connection floating around, but the doc talks about tearing the
> entire connection down. uldap_connection_cleanup() documents pretty
> much the same behavior.
> 
> Since close() and cleanup() seem so close to eachother, should we make
> them do the same thing and add some operation that's more clearly
> unlocking/releasing the pooled connection?
> 
> (authnz_ldap's r->pool cleanup would call unlock()/release() pretty
> much exclusively)


The actual functionality that they perform, unlocking vs. tearing down, is a key part of how util_ldap works.  Granted that the names of the functions might be technically mis-leading.  This is mostly due to code evolution.  The problem from an API perspective is that in most cases we don't want the user to tear down a connection because that would make the connection caching useless.  For the most part, the connection cache is responsible for tearing down the connections.  The user just needs to release the connection when finished.  Maybe what really needs to be done is to eliminate connection_open() and combine it with connection_find() so that util_ldap is solely responsible for either reusing or creating connections.  Then rename  connection_close() to connection_release() so that the reverse is also true.  Connection_Open() and connection_cleanup() would be converted to internal functions to util_ldap.  Creating and destroying connections needs to be completely handled by util_ldap.  The user just needs to be given a connection to use and then release it when finished.

Brad