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 <[EMAIL PROTECTED]> 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
>
