On 4 Oct 2010, at 09:36, Jukka Zitting wrote:
> Hi,
>
> On Mon, Oct 4, 2010 at 10:05 AM, Ian Boston <ieb@tfd.co.uk> 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
|