On 11/28/07, Christian Boos <[EMAIL PROTECTED]> wrote: > >> If I'm reading perm.py correctly PermissionCache only caches repeated > >> permission checks on a specific resource and action and not repeated > >> checks on different resources in the same realm. This means that the > >> apply_ticket_permission function will generate hundreds if not thousands > >> of cache misses for larger Trac installations. > >> > > Correct. All permission checks are handed off to IPermissionPolicy > > implementations, so it's impossible (currently) for the permission > > system to know whether more aggressive caching is acceptable.
> If I'm reading perm.py correctly PermissionCache only caches repeated > permission checks on a specific resource and action and not repeated > checks on different resources in the same realm. I took this to mean that Jonas wanted clarification as to whether the permission cache key was (resource, action) vs. (realm, action), where of course it is the former. > In the scope a given request, there will be only one cache miss for a > given resource/action. That's because the actual _cache of permissions > is shared from one PermissionCache instance to another. So "repeated > checks on different resources in the same realm" (or not in the same > realm for that matter) are indeed cached. I'll assume this explanation is for Jonas's benefit ;) > A different approach would be to move that _cache at the level of the > PermissionSystem component, in order to share it across requests, with > the user as a toplevel key and some mechanism to prune that cache. The > trade-offs there would be on the down side some degree of locking > contention on that cache, on the up side, the decisions for /all/ > permission policies would be cached and the checks won't have to be > repeated for every request. I think we should wait to see if it's actually a problem first. It could easily be logging causing it, or the patch could fix it. -- Evolution: Taking care of those too stupid to take care of themselves. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
