jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Padraic Hannon" <...@wasabicowboy.com>
Subject [OCM] Second Level Cache Update
Date Thu, 03 Apr 2008 16:10:50 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message