3 Replies Latest reply on Feb 2, 2012 5:16 AM by Galder Zamarreño

    How to use Infinispan 5.1.Final as Second Level Cache for Hibernate 4.0.1.Final ?

    Alex Makarenko Newbie

      Hi!

       

      I've got a question about issue with custom commands when Infinispan is used as a second level cache for Hibernate, and overall usability of hibernate-infinispan libarary.

       

      First of all, after upgrading from Hibernate 4.0.0.Final to 4.0.1.Final I am immediately got NPE in InfinispanRegionFactory during initialization of SessionFactory.

      Obviously, application failed to start with such an exception.

       

      I have next setup:

       

      • Jetty as servlet container with Infinispan bound to JNDI context. So Infinispan is shared between all web apps on that server. Infinispan libraries are located in Server ClassLoader.
      • Multiple web apps have their own Hibernate libraries, loaded by local WebApp ClassLoaders.

       

      When I’ve got NPE in InfinispanRegionFactory I tried to figure out what I did wrong, and then I saw that code:

       

      ComponentRegistry cr = cache.getComponentRegistry();
      
      cr.getComponent(CacheCommandInitializer.class).setRegionFactory(this);
      
      GlobalComponentRegistry globalCr = cache.getComponentRegistry().getGlobalComponentRegistry();
      …setRegionFactory(this);
      

       

      As I understand, there are some custom commands now, bundled within hibernate-infinispan.jar.

       

      My first question is – when and how they should be registered in Infinispan, if Infinispan and hibernate are located in different ClassLoaders and have different lifecycle?

      Second question is – what is a lifecycle policy for such commands in environments with shared Infinispan instance and multiple SessionFactories?

       

      I don’t know what ComponentRegistry and GlobalComponentRegistry are, but they should better be wise enough to have local copies of components for each application (otherwise calls like “setRegionFactory(this)” will overwrite all previous RegionFactory instances and there will be only one effective RegionFactory – the last one registered).

      Also, it looks like a potential source for memory leaks – if applications will be unloaded by app server, all references to RegionFactories should be removed from centralized resources.

       

      Please correct me, if I am wrong.

        • 1. Re: How to use Infinispan 5.1.Final as Second Level Cache for Hibernate 4.0.1.Final ?
          Galder Zamarreño Master

          Alex Makarenko wrote:

           

          My first question is – when and how they should be registered in Infinispan, if Infinispan and hibernate are located in different ClassLoaders and have different lifecycle?

          These custom commands need to be registered with Infinispan when Infinispan cache manager is built. These commands were built to handle evictAll situations which previously were handled by using the cache as a way to send messages around the cluster, which really was a hack.

           

          To be honest, if it's possible for different web apps to use different Hibernate versions, you should use the right hibernate-infinispan.jar and infinispan-core.jar along with each app. For example, if you have:

          - Hibernate 4.x, use Infinispan 5.1.0.FINAL

          - Hibernate 3.6.x, use Infinispan 4.2.1.FINAL

           

          So, I can't really see how you can decouple Infinispan and have a shared cache manager if you're bound to use different Hibernate versions. In some situations things might not work as expected.

           

          Are you clustering the Infinispan 2LC?

           

          Alex Makarenko wrote:

           

          When I’ve got NPE in InfinispanRegionFactory I tried to figure out what I did wrong, and then I saw that code:

           

          ComponentRegistry cr = cache.getComponentRegistry();
           
          cr.getComponent(CacheCommandInitializer.class).setRegionFactory(this);
           
          GlobalComponentRegistry globalCr = cache.getComponentRegistry().getGlobalComponentRegistry();
          …setRegionFactory(this);
          

           

          ...

           

          I don’t know what ComponentRegistry and GlobalComponentRegistry are, but they should better be wise enough to have local copies of components for each application (otherwise calls like “setRegionFactory(this)” will overwrite all previous RegionFactory instances and there will be only one effective RegionFactory – the last one registered).

          Also, it looks like a potential source for memory leaks – if applications will be unloaded by app server, all references to RegionFactories should be removed from centralized resources.

          You have a point here. At the cache level, this is not a problem because a cache is associated with an application, but changing the global component registry could have, in a shared environment, have an impact on the other region factories because they'd be overriden. I've created https://hibernate.onjira.com/browse/HHH-7007 to find a better solution.

          1 of 1 people found this helpful
          • 2. Re: How to use Infinispan 5.1.Final as Second Level Cache for Hibernate 4.0.1.Final ?
            Alex Makarenko Newbie

            Galder Zamarreño wrote:

             

            Are you clustering the Infinispan 2LC?

             

            Yes, the 2LC is clustered with INVALIDATION.

            Since original data could be fetched from DB at any time - invalidation is enough for me.

             

            Solution with dedicated Infinispan cache managers for every webapp looks like overkill for me, since thay will require their own communication channels, multicast configs, etc.

            • 3. Re: How to use Infinispan 5.1.Final as Second Level Cache for Hibernate 4.0.1.Final ?
              Galder Zamarreño Master

              Different Infinispan cache managers can share the JGroups transport which is what drive the communications and multicast configurations. This is done by plugging a JGroupsChannelLookup implementation and share that between all cache managers.

               

              That's what AS7 does and in fact, if you're in need to do all this, you might as well deploy on AS7 rather than on Jetty and your life will be easier

               

              FYI, thanks for pointing the issue about the region factory set method call. I created an issue for it (https://hibernate.onjira.com/browse/HHH-7007) and this is now fixed.

              1 of 1 people found this helpful