Hi Guys,

I am wondering if we can make the lock mechanism in ApacheDS more flexible. 
Right now, both the read lock and the write lock seem to be global, which does 
not allow concurrent write to different entities in the LDAP store. If we can 
make the lock more granular, it would improve the throughput of the ApacheDS 
service. For example, we can have one thread serving one ldap session trying to 
read, and another thread serving another ldap session applying some 
modifications.

Another issue with the current lock mechanism is that, a lock is not associate 
with the owner, leading to a strange behavior.

Here is an example. I would like to setup ApacheDS in this way by overriding 
the simple authentication class so that if a user fails to authenticate 
himself, an external authentication service is used. When external 
authentication succeeds, I would like to insert this user as an entry in the 
ldap store or update his password. Users usually do a ldap binding with 
password to authenticate to ApacheDS. During the handling of the bind request, 
ApacheDS will first request a readlock through the DefaultOperationManager, 
then call the simple authenticator to authenticate the user. In my case, if the 
authentication fails, then external authentication service is used instead. The 
problem comes at when trying to insert the user as a new entity or update its 
password, the write lock can't be obtained because it is still in the bind 
process and the read lock is only released after the bind finishes.  If we keep 
track of the owner of the lock, we would be able to allow the promotion of 
read-lock to write-lock as how lock is done in many database systems.

Regards,

James

Reply via email to