Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      OCM should work with a cache manager.

      • The Spring frameworks offer a nice solution to integrate an application with a cache manager (based on AOP).
      • Which cache framework to use ? oscache, JCS, ...
      • A more detailled proposal is required
      1. ocm_cache.zip
        16 kB
        Padraic Hannon

        Activity

        Hide
        Ard Schrijvers added a comment -

        see OCM-60

        Show
        Ard Schrijvers added a comment - see OCM-60
        Hide
        Samba Siva Rao Kolusu added a comment - - edited

        Why not use JCS, Apache's own JCache implementation ? I personally feel Apache Products are more reliable among the Open Source ones.

        Actually, A pluggable Cache mechanism would be ideal, so that I can use any Caching software that implements JCache Specification.

        Show
        Samba Siva Rao Kolusu added a comment - - edited Why not use JCS, Apache's own JCache implementation ? I personally feel Apache Products are more reliable among the Open Source ones. Actually, A pluggable Cache mechanism would be ideal, so that I can use any Caching software that implements JCache Specification.
        Hide
        Padraic Hannon added a comment -

        Here is the work I have done so far. I do not have test cases specific for this implementation as I have been working on these files against my existing internal test cases. To use this from within Spring (it requires SessionFactory to make everything work), wire it up as a replacement to JcrMappingTemplate:

        <bean id="secondLevelCache"
        class="org.apache.jackrabbit.ocm.objectconverter.cache.ehcache.SynchronizedEhCacheObjectCache"
        singleton="true">
        <constructor-arg index="0" ref="jcrSessionFactory"/>
        </bean>
        <bean id="vdmMappingTemplate"
        class="org.apache.jackrabbit.ocm.spring.JcrCachedMappingTemplate">
        <constructor-arg index="0" ref="jcrSessionFactory"/>
        <constructor-arg index="1" ref="jcrMappingDescriptor"/>
        <constructor-arg index="2" ref="secondLevelCache"/>
        <property name="allowCreate" value="false"/>
        </bean>

        Show
        Padraic Hannon added a comment - Here is the work I have done so far. I do not have test cases specific for this implementation as I have been working on these files against my existing internal test cases. To use this from within Spring (it requires SessionFactory to make everything work), wire it up as a replacement to JcrMappingTemplate: <bean id="secondLevelCache" class="org.apache.jackrabbit.ocm.objectconverter.cache.ehcache.SynchronizedEhCacheObjectCache" singleton="true"> <constructor-arg index="0" ref="jcrSessionFactory"/> </bean> <bean id="vdmMappingTemplate" class="org.apache.jackrabbit.ocm.spring.JcrCachedMappingTemplate"> <constructor-arg index="0" ref="jcrSessionFactory"/> <constructor-arg index="1" ref="jcrMappingDescriptor"/> <constructor-arg index="2" ref="secondLevelCache"/> <property name="allowCreate" value="false"/> </bean>
        Hide
        Padraic Hannon added a comment - - edited

        Please disregard the patch I created. I messed up due to not taking the time to understand what was going on. I am going to remove the patch. I thought I was working on a second level cache. The RequestObjectCache is a first level cache which as Christophe pointed out and I didn't follow is basically used only to prevent infinite recursion.

        Show
        Padraic Hannon added a comment - - edited Please disregard the patch I created. I messed up due to not taking the time to understand what was going on. I am going to remove the patch. I thought I was working on a second level cache. The RequestObjectCache is a first level cache which as Christophe pointed out and I didn't follow is basically used only to prevent infinite recursion.
        Hide
        Padraic Hannon added a comment -

        I'm working on ehcache now.

        I probably was confusing in my statement re. hibernate. I was looking at the hibernate Cache/CacheProvider pattern as starting point for how we might want to create a pluggable infrastructure. I do not want to rely on their infrastructure. However, since there stuff is easily configurable I thought it would be good to look at what they did as an example.

        Show
        Padraic Hannon added a comment - I'm working on ehcache now. I probably was confusing in my statement re. hibernate. I was looking at the hibernate Cache/CacheProvider pattern as starting point for how we might want to create a pluggable infrastructure. I do not want to rely on their infrastructure. However, since there stuff is easily configurable I thought it would be good to look at what they did as an example.
        Hide
        Kris Kempa added a comment -

        I fully agree with Ian:
        +1 for Ehcache.

        http://ehcache.sourceforge.net.

        Show
        Kris Kempa added a comment - I fully agree with Ian: +1 for Ehcache. http://ehcache.sourceforge.net .
        Hide
        Ian Boston added a comment -

        Sorry to interrupt

        Please don't bind to Hibernate, if you do, every other user if Hibernate will be forced to use the same version of Hibernate or not use Jackrabbit. We (Sakai) already cant use Alfresco for this reason.

        The same goes for binding directly to any implementation that locks the jvm to a particular version of that jar. We have found the if you feel you need a 3rd party caching lib, ehcache is Ok since the API exists, is relatively stable and doesn't require 1001 other jars.

        That being said, I thought that there were plenty of other cache mechanisms in Jackrabbit that did full management and expiry.

        Just to give you an idea of the hibernate issues, it binds to specific aop and cglib versions.... so does spring....

        at the moment Jackrabbit is nice to work with because it doesnt cause any problems in this area.

        All IMHO

        Show
        Ian Boston added a comment - Sorry to interrupt Please don't bind to Hibernate, if you do, every other user if Hibernate will be forced to use the same version of Hibernate or not use Jackrabbit. We (Sakai) already cant use Alfresco for this reason. The same goes for binding directly to any implementation that locks the jvm to a particular version of that jar. We have found the if you feel you need a 3rd party caching lib, ehcache is Ok since the API exists, is relatively stable and doesn't require 1001 other jars. That being said, I thought that there were plenty of other cache mechanisms in Jackrabbit that did full management and expiry. Just to give you an idea of the hibernate issues, it binds to specific aop and cglib versions.... so does spring.... at the moment Jackrabbit is nice to work with because it doesnt cause any problems in this area. All IMHO
        Hide
        Thomas Mueller added a comment -

        I was confused because the description said 'the PersistenceManager'. I see this is about OCM.

        Show
        Thomas Mueller added a comment - I was confused because the description said 'the PersistenceManager'. I see this is about OCM.
        Hide
        Padraic Hannon added a comment -

        This patch provides the following:

        1) Updates to RequestObjectCacheImpl to provide observation to flush based on jcr events
        2) Updates ObjectCache interface to extend Map (first step in allowing other caches)
        3) Provides the ability to set the cache on the ObjectContentManager and have that ripple to the ObjectConverterImpl (so we can use a config file to set cache after construction of the content manager)
        4) Simple cache unit tests

        I was going to go down the hibernate cache provider route, but felt it was a bit overkill.

        Tomorrow I will create instances of the cache using EhCache.
        From there I think I will try a Tangosol one.

        Show
        Padraic Hannon added a comment - This patch provides the following: 1) Updates to RequestObjectCacheImpl to provide observation to flush based on jcr events 2) Updates ObjectCache interface to extend Map (first step in allowing other caches) 3) Provides the ability to set the cache on the ObjectContentManager and have that ripple to the ObjectConverterImpl (so we can use a config file to set cache after construction of the content manager) 4) Simple cache unit tests I was going to go down the hibernate cache provider route, but felt it was a bit overkill. Tomorrow I will create instances of the cache using EhCache. From there I think I will try a Tangosol one.
        Hide
        Padraic Hannon added a comment -

        Until we have a robust cache framework we should remove the current implementation as it poses some problems the two that I've run into are:

        1) Unbounded HashMap with no size limits
        2) No observation mechanism to detect underlying changes to jcr nodes

        Show
        Padraic Hannon added a comment - Until we have a robust cache framework we should remove the current implementation as it poses some problems the two that I've run into are: 1) Unbounded HashMap with no size limits 2) No observation mechanism to detect underlying changes to jcr nodes

          People

          • Assignee:
            Ard Schrijvers
            Reporter:
            Christophe Lombart
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development