we can use ehcache to counter the memory issue(we can defer this step though)
On 14-Jun-2011 6:56 PM, "Stefan Seelmann" <seelm...@apache.org> wrote: On Tue, Jun 14, 2011 at 2:29 PM, Emmanuel Lécharny <elecha...@apache.org> wrote: > On 6/13/11 11:19 ... I wonder why we need an alias cache? For fast lookup of the search base in case the "find" bit is set? > - create an AliasInterceptor to manage the Add and Delete operations done on > alias entries (and... You mean that interceptor is used to update the cache, right? > - modify the Search to handle a set of met aliases. Yep. > I'll proceed by creating the alias interceptor first, and Ill remove the > part that handle Alias... Ok. Two other issues I see with the new algorighm: - It is efficient if there are only few aliases. But if a user adds million of alias entries we may get a memory problem. I just want to mention that to make clear that such an issue may occur. I don't think it makes sense to create so many alias entries, but I saw an example where group membership was implemented using aliases... - It is possible that duplicates occur, for example if an alias enlarges the initial search scope by pointing to a parent of the initial search base. I think duplicates can be avoided by tracking each search base and filter result enties within already processed search bases. Kind Regards, Stefan
