On 22 Nov 2010, at 13:27, Felix Meschberger wrote: > > This sounds wrong, though. Where is this happening ? > > Looking at the code, the AuthorizableResourceProvider.getResource method > just returns null if a user/group of said name does not exist. > > Regards > Felix
Yes, if the resource does not exist, (null) then JcrResourceResolver.resolveInternal starts a search which used getChildInternal on parent = /system/userManager/user childName = userID JcrResourceResolver.getChildInternal If the child does not exist, the implementation gets the parent and iterates through all children looking for an alias. Hence looking at all items in the iterator, line 1101 in the code I am looking at. Since this functionality is needed and used for JcrResources, where the number of child nodes is always acceptable, then its Ok. (well, strictly speaking looping through items to do a search is never acceptable is the number of items is unbounded, but I am turning a blind eye to that) Its only a problem when the ResourceProvider has so many child nodes as to make the scan take too long. The downside of this is, it causes all authorizable nodes to be loaded into the shared item cache which requires a read lock for each one. Not a problem if there are no writes happening on other threads, but it will block and be blocked if there are writes. That also evicts everything else out of the cache, We cant do anything about that here, but we can, afaict avoid the listChildren behaviour. I have tried returning null to the listChildren and it looks like thats Ok, but I haven't done extensive tests yet. Ian
