On 4 Oct 2010, at 09:36, Jukka Zitting wrote: > Hi, > > On Mon, Oct 4, 2010 at 10:05 AM, Ian Boston <[email protected]> wrote: >> Do you think your work on JCR-2699 will make reads truly concurrent with >> no blocking or will there always be a part of the code base that is >> essentially single threaded? > > The one big remaining synchronization block is that in the persistence > managers where they control access to the underlying persistence > store. This was a hard requirement for our older database persistence > managers that had to synchronize access to the potentially > thread-unsafe single JDBC connection they were using. Thanks to the > connection pooling support contributed in JCR-1456 we should now be > able to avoid also that problem. I'll be looking at that shortly. > > Of course, the next concurrency bottleneck will then be the underlying > persistence store and ultimately the disk where the content gets > stored, but there are existing solutions (clustering, RAID, etc.) for > that.
Have you thought of replacing the LRUMap instances with a LRU map impl based on ConcurrentHashMap that evicts when full. I did a brain dead Map impl and replaced the LRUMaps in AbstractPrincipalProvider and DefaultPrincipalProvider and I think I saw significantly fewer blocked sections of the thread traces in YourKit. Ian > > BR, > > Jukka Zitting
