Hi,
On Thu, Feb 27, 2014 at 1:02 PM, Jukka Zitting <[email protected]> wrote: > Hi, > > On Tue, Feb 25, 2014 at 2:35 AM, Angela Schreiber <[email protected]> wrote: >> i tried this out last year and it was terribly slow. > > We were too busy at the time to dig deeper, but I'm still surprised > about the result. Are we sure the draft implementation didn't have > some order-of-magnitude performance bottlenecks that couldn't be > avoided? > > With the current implementation, to get permissions of a principal for > a given path, we need to read the content stored at: > > /jcr:system/rep:permissionStore/<principal>/<hash(/path/to/node)>/... > > If we instead stored the same information along the actual path being > accessed, the permissions could be read at: > > /path/to/node/:permissions/<principal>/... > > AFAICT there should be no reason why accessing the latter would be any > more expensive than the former, and a variety of reasons (locality of > access, etc.) to expect it to be notably faster. If implemented like > this, there would be no central point of contention like we now have > with the modCount property. the current implementation allows to read all ACLs for a given principal very efficiently at once with no false hasNode() accesses. as the size of the ACLs is known beforehand for each principal, it can quickly be decided if it's worthwhile to load all ACLs for a given principal set or not. But you're idea is certainly worth to follow later on. so far we focused on assemble the ACLs directly then traversing, but storing the pre-compiled permissions in the content was IIRC never tried. regards, toby
