jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu" <the.mindstorm.mailingl...@gmail.com>
Subject Re: Working with JCR in highly concurrent applications
Date Fri, 22 Sep 2006 06:51:50 GMT
On 9/22/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On 9/22/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> > On 9/22/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> > > Hmm, I've never thought about it from that angle.
> >
> > There are always corner scenarios that you can take advantage of ;-).
>
> True hacker spirit! :-)
>
> > > There are some
> > > internal caches that get modified even in read-only sessions. I don't
> > > think those data structures are thread-safe, so you might end up
> > > corrupting the internal state.
> >
> > Yes, I've noticed those but I remember most of them were synched
> > collections. However, I will try to recheck. If you can point some
> > places upfront that would be great, and would limit my research a lot.
>
> Check at least the CachingHierarchyManager and ItemStateReferenceCache classes.
>

I think I have pretty good news for me :-).

CachingHierarchyManager uses synchronized blocks around all cache operations.

ItemStateReferenceCache is used from either LocalItemStateManager
(that deals with updatable nodes) and from SharedItemStateManager
(deals with shared states/read-only state). And the 2nd one looks
pretty good from concurrency point of view (I still have to study it
in more detail).

So, I guess I can give it a try, with my extremely corner scenario
(and I would like this to be very clear to other users, so that they
will not try it without investigating it in depth).

./alex
--
.w( the_mindstorm )p.

> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>

Mime
View raw message