jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: [OCM] Second Level Cache Update
Date Fri, 04 Apr 2008 08:39:10 GMT
Paddy,

Thanks a lot to work on it. it is a great help. Can we have an access
to the current code ?
FYI, there is a refactoring of Spring integration done under ground by
Sebastien. I will update it in subversion.

br,
Christophe


On Thu, Apr 3, 2008 at 6:10 PM, Padraic Hannon <pih@wasabicowboy.com> wrote:
> I've been working for a while on implementing a second level cache system
>  for OCM. I have gone down several routes and finally have one I think works
>  well. At the moment I am debugging some threading issues (solved via
>  synchronization, but I'd like to make it safe without doing so if possible)
>  that cause one of my simple tests to fail. I do have some test that I've
>  been running with interesting results.
>  Both versions of the test use OCM to load the same node using an attribute
>  ie a simple xpath query and convert the node to an object with all bean and
>  collection references lazy loaded. The lazy loaded beans and collections are
>  not read during the test. The test starts with two concurrent threads and
>  grows to 128 threads. There is a single main thread that does 256 get
>  attempts on the object. Each of the other threads executes as often as
>  possible (with a 10 ms sleep in between executions) until the primary thread
>  is finished.
>
>  The OCM query code is:
>
>  protected Object forId(Class classToFind, Long id) {
>       org.apache.jackrabbit.ocm.query.QueryManager queryManager =
>  getJcrMappingTemplate().createQueryManager();
>       org.apache.jackrabbit.ocm.query.Filter filter =
>  queryManager.createFilter(classToFind);
>       filter.addEqualTo("id", id);
>       Query query = queryManager.createQuery(filter);
>       return getObjectFromQuery(query);
>  }
>
>  protected Object getObjectFromQuery(Query query) {
>      Collection results = getJcrMappingTemplate().getObjects(query);
>       if (results != null && !results.isEmpty()) {
>            Iterator resIt = results.iterator();
>            return resIt.next();
>       }
>       return null;
>  }
>
>
>  For the non-cached plain OCM:
>
>  testConncurentForId: run [1] threads [2.0] time taken = 2339 ms
>  testConncurentForId: run [2] threads [4.0] time taken = 3597 ms
>  testConncurentForId: run [3] threads [8.0] time taken = 9189 ms
>  testConncurentForId: run [4] threads [16.0] time taken = 22105 ms
>  testConncurentForId: run [5] threads [32.0] time taken = 47406 ms
>  testConncurentForId: run [6] threads [64.0] time taken = 96337 ms
>  testConncurentForId: run [7] threads [128.0] time taken = 236061 ms
>
>  For a cached version using EhCache:
>
>  testConncurentForId: run [1] threads [2.0] time taken = 508 ms
>  testConncurentForId: run [2] threads [4.0] time taken = 616 ms
>  testConncurentForId: run [3] threads [8.0] time taken = 1024 ms
>  testConncurentForId: run [4] threads [16.0] time taken = 2508 ms
>  testConncurentForId: run [5] threads [32.0] time taken = 10738 ms
>  testConncurentForId: run [6] threads [64.0] time taken = 26644 ms
>  testConncurentForId: run [7] threads [128.0] time taken = 58736 ms
>
>  The speed increase is notable, however, my current implementation has a few
>  problems:
>
>  1) Cache flushing is extremely coarse grained (I'm doing a read mostly app
>  so I haven't focused on this much)
>  2) Flushing based on observation is currently a bit flaky and has some race
>  conditions I need to work out
>  3) The entire system is built around using the ocm-spring infrastructure
>  4) The cache is assumed to be tied to a specific JcrMappingTemplate instance
>  and so does not enforce any security constraints on reads.
>
>  I am going to spend time over the next week cleaning up 1 and 2 above.
>  However, for simplicity using the ocm spring infrastructure has been a great
>  help. I basically created a new JcrMappingTemplate called
>  CachedJcrMappingTemplate. This handles creating a cached version of the
>  objectcontentmanager and objectconverter which rely on SessionFactory and
>  the Jcr callback mechanisms to ensure that the lazy loaded objects can be
>  loaded even after their originating session is closed. The cache access is
>  entirely hidden within the CachedObjectContentManager and
>  CachedObjectConverter instances. All in all, things seem to be working and
>  the system is much simpler that my previous attempts. In addition, they can
>  be wholly contained within their own project and one can use spring to
>  switch in/out the JcrMappingTemplate.
>
>  -paddy
>

Mime
View raw message