-
1. Re: How to use Infinispan 5.1.Final as Second Level Cache for Hibernate 4.0.1.Final ?
galder.zamarreno Jan 31, 2012 5:16 AM (in response to alexmak)1 of 1 people found this helpfulAlex 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.
-
2. Re: How to use Infinispan 5.1.Final as Second Level Cache for Hibernate 4.0.1.Final ?
alexmak Feb 1, 2012 1:12 PM (in response to galder.zamarreno)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.zamarreno Feb 2, 2012 5:16 AM (in response to alexmak)1 of 1 people found this helpfulDifferent 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.