directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: Alias cycle detection
Date Wed, 15 Jun 2011 10:14:42 GMT
On 6/15/11 11:21 AM, Howard Chu wrote:
> Alex Karasulu wrote:
>> On Mon, Jun 13, 2011 at 5:39 PM, Emmanuel 
>> Lecharny<>  wrote:
>>> Alias cycle detection
>>> ---------------------
>>> There is an unsolved question about how we should detect Alias 
>>> cycles. Right
>>> now, we check for cycles *before* they are created. The alternative 
>>> would be
>>> to stop any search that could lead to an infinite loop.
>> That would slow down reads. The best is to stop this from happening
>> with write operations: meaning doing the computation to detect and
>> prevent the cycle then and there instead of exhausting the search
>> process to deal with such wicked constructs.
> You may be being over-paranoid here. First a client has to explicitly 
> request alias dereferencing and most of them don't by default, 
Actually, they do. The default for people using JNDI is to Deref 
("When you use Sun's LDAP service provider, you can control how aliases 
are dereferenced in one of four ways, by using the 
"java.naming.ldap.derefAliases" environment property, as shown in the 
following table. If this environment property is not set, then the 
default is "always".")
> so in general reads will be unaffected. Also the DB operations 
> required to detect a cycle at write time are the kinds of things you 
> would already be performing efficiently in a search. Doing them at 
> search time is far better from a concurrency perspective because 
> you're only doing read operations inside a reader transaction, and 
> nothing touched inside the DB needs to stay locked for long. If you're 
> doing these searches during a write operation then you're going to 
> accumulate huge numbers of locks that must be held until the write 
> transaction commits.

And as I said in a previous mail, detecting cycle during search is 
probably totally unnoticeable, wrt performances.Of course, with millions 
of aliases, that would be a different problem, but in this case, I would 
likely tell the user to switch to another LDAP server :)

Emmanuel L├ęcharny

View raw message