I don't know why this was added instead of adding eager entry loading.  It was added during one of the 1.5.x iterations.  We should get rid of this notAliasCache optimization here in ExceptionUtils since all ContextOperations will soon eagerly load the target entry if present.  The check for aliases will not incur the overhead that this cache hopes to do away with.  Instead this eats more memory, more contention, and will actually cost more in processing time to match the DN.  This is an example of premature optimization becoming more of a problem then it solves.  Cache description is here:

     * A cache to store entries which are not aliases.
     * It's a speedup, we will be able to avoid backend lookups.
     * Note that the backend also use a cache mechanism, but for performance gain, it's good
     * to manage a cache here. The main problem is that when a user modify the parent, we will
     * have to update it at three different places :
     * - in the backend,
     * - in the partition cache,
     * - in this cache.
     * The update of the backend and partition cache is already correctly handled, so we will
     * just have to offer an access to refresh the local cache. This should be done in
     * delete, modify and move operations.
     * We need to be sure that frequently used DNs are always in cache, and not discarded.
     * We will use a LRU cache for this purpose.
    private final LRUMap notAliasCache = new LRUMap( DEFAULT_CACHE_SIZE );


This is totally unnecessary and a distraction.  Yeah we get some slight performance advantage for a few months.  Then it becomes a problem.

If we add temporary solutions then we should make sure we note it in JIRA so we can later go back and cleanup the workaround.  Also having an issue that is required to be completed before cleaning up the no longer needed code is a good idea.  Like for example a "add eager loading of target entries to OperationContexts" could be an issue that needs to occur before the "Remove not alias cache in ExceptionInterceptor". 

This code (an optimization in dev cycle) though is not a case where it is at all warranted.  It is an example of a performance improvement that will be determimental to performance as the architecture shifts to accomodate these performance bottlenecks.  This is why I fear premature optimizations.  Optimizations need to occur while producing release candidates before a major GA release, or subsequent to the GA in maintenance releases.  Instead of optimizing a development branch we need to shift the architecture to fix the problem.

As a rule we should not optimize in development releases.  Optimization should be left to RC releases before a GA or in maintenance releases afterwards.


Microsoft gives you Windows, Linux gives you the whole house ...