On 2 Oct 2010, at 02:15, Ian Boston wrote: > Hi, > I have been trying to work out why Sling is showing Single Threaded behaviour > with authenticated users to areas of the JCR that are not read public. > > I think that this is because there are concurrent threads using the > ACLProvider via the DefaultSecurityManager sharing single system session that > is synchronised inside the ItemManager.getNode et al. method. > > This does not happen where the JCR is public read since resolution of the > ACLs is bypassed and so no single threading is seen. > > So the question: > Am I diagnosing the problem correctly ? > What would be the impact of customising this area of the code base to use one > systemSession per thread and avoid the single threadedness, which is having a > big impact on the performance of our deployments ? > > TIA > Ian
I have had a look at fixing this and its a major modification to all Access Control Providers as the single systemSession per workspace is saved in the abstract base class. It happens in all Jackrabbit instances since around 1.6 when item tree is not 100% read granted. Any pointers on this would be really appreciated as its becoming a deal breaker for our use of Sling and Jackrabbit. We cant use Jackrabbit if it is a single threaded server for read access where some read is denied. Ian
