On 6 Jan 2010, at 22:11, Felix Meschberger wrote: > Hi all, > > Today I stumbled upon a potential problem with the JCR Session Pooling > we have in the JCR Base bundle. > > Some time ago, we disabled session pooling by default. Only today I > actually set this default for the Embedded Jackrabbit bundle (see > SLING-1272). > > The problems with session pooling are manyfold, some of the issues are: > > * Only works with SimpleCredentials authentication > * Wrong level of abstraction: such optimizations are the task of the > repository implementation and not of the user > * Cleanup of the session for reuse is brittle and timeconsuming > (due to a JCR search to ensure unlocking transient locks) > * Little to no gain in performance (in fact performance is even > lower than using plain Jackrabbit Sessions. > > The only real use of the current session pooling, we might discuss, is > the optional limitation of concurrent requests per user. But even this > feature is disabled by default. > > For these reasons, I think we should remove the Session Pooling support > from the JCR base bundle. > > WDYT ?
What happens to compiled ACL's if there is no session pooling. IIRC where the JCR is not in "everyone can read everything" mode, the Session is the location where compiled ACL's are stored. If the session is not pooled every request has to recompile the ACLs. This wont be noticed for situations where most reads dont need an ACL, but where they do and there are a high number of ACL (or the cost of resolving and compiling the ACLs is higher due to complex rules) then removing session pooling is going to have an impact. The ACL resolution mechanism in DefaultAccessControlManager is highly optimised and very fast once the ACL has been compiled, which is good since its an extremely high traffic area of the Jackrabbit code base, but compilation of the ACL is not fast particularly where there are many ACLs effecting a single node. I suspect that if you are comparing performance in "everyone can read everything" you wont see any impact, have you tried to see what happens when there is a more complex ACL structure that is compiled ? Also, I was told once that JCR XASessions and the associated SecurtiyManager, and all JCR core thing with an init() attached to the session was a heavy and expensive object (relative term) that should be re-used, has this changed ? I am not going to vote on this, but I do want to discuss it since when I first looked at Sling I was relieved to see session pooling in place. I could also be that I am miss-understanding session pooling, but I thought the key feature was that if a user came back, and there was a session in the pool that they had used before, they got the same session back and were able to re-use all the work of previous requests in the ACL area. Ian > > Regards > Felix
