On 6/15/11 11:21 AM, Howard Chu wrote:
Alex Karasulu wrote:
On Mon, Jun 13, 2011 at 5:39 PM, Emmanuel
Lecharny<[email protected]> 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
Always.(http://download.oracle.com/javase/jndi/tutorial/ldap/misc/aliases.html)
("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 :)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
