Why LDAPObject.._ldap_object_lock around library calls?
michael at stroeder.com
Wed May 5 21:58:01 CEST 2004
Ken Key wrote:
> I need to have two threads, a Producer and Consumer (relative to LDAP),
> translates the results into
> a form my proxy protocol and puts it on the work result Queue.
I probably don't understand what you're after. However I try to give some
>>According to related postings on the OpenLDAP lists libldap_r is
>>on a per-connection basis. Therefore linking with libldap_r improves the
>>situation since a finer-grained locking is used in LDAPObject class (see
> However, the lock is still across all methods of an instance of the
> LDAPObject, and thus in force for all operations on the connection,
> across all threads. That's the problem.
Your threads should use different LDAP connections thus LDAPObject instances.
> I was trying to determine if there were reasons beyond the
> underlying binary OpenLDAP client libraries that the locking was in
The OpenLDAP libs are the problem. Nothing in python-ldap requires the locks.
> If not, I was thinking of overriding the _ldap_call() in
> my own class and eliminating it, since the ldap_r is a requirement
> for my proxy's environment.
Don't do this! The OpenLDAP libs are not re-entrant within one connection
context. See OpenLDAP mailings list archives for details.
More information about the python-ldap