[hibernate-dev] Question about Hibernate 4.0 Infinispan second level cache usage...

[Paul Ferraro]

On Tue, 2011-08-16 at 10:45 -0400, Scott Marlow wrote:
> On 08/16/2011 10:26 AM, Sanne Grinovero wrote:
> > Hi Scott,
> > demanding people to configure a new cache for each application is very
> > tricky because of ISPN-658, unless you're referring to creating a
> > whole new instance of Infinispan, with a dedicated new CacheManager
> > and either starting a new JGroups channel or using the JGroups
> > multiplexer Paul had written. In case of the multiplexer I'm not sure
> > if the channel identifiers could be assigned dynamically according to
> > application deployments and at the same time be consistent with the
> > identifier numbers chosen on other application server instances, where
> > different applications might be deployed or in different order, so my
> > guess is that people would need to deal with additional JGroups
> > configurations and handle the burden of extra network ports to be
> > configured and managed.
> >
> > Using a rich key containing also the PU and application name seems the
> > best option to me, and I wouldn't worry too much about the additional
> > payload as that needs to be transferred anyway: I don't see how the
> > receiving side could route the command to the proper application
> > otherwise.
> >
> > I think it would be nice - if possible - to not change the
> > regionfactory contract but in some way wrap the keys normally
> > produced, to keep it simple and avoid the payload for those cases it's
> > not deployed in AS7.
> 
> I could try setting AvailableSettings.CACHE_REGION_PREFIX to the 
> application scoped pu name.  That seems to get added to the region name 
> (region would then be: application name + PU jar name + PU name + entity 
> class).
> 
> Would that be likely to work?

I think so.  This is what I was getting at in terms of how to augment
the cache named generated by the hibernate-infinspan provider to include
the pu name.  I originally suggested having the JPA integration code
populate a persistence property that could be recognized by the
hibernate-infinispan provider.  The CACHE_REGION_PREFIX seems to fit the
bill.  I would just be careful to make sure the existing use case for a
region prefix is still respected (not that I know for sure what that
is).

> >
> > Sanne
> >
> >
> > 2011/8/16 Scott Marlow<smarlow at redhat.com>:
> >> I'm looking at o.h.c.i.InfinispanRegionFactory and wondering how best to
> >> configure the 2lc for AS 7.1.  After a recent forum discussion and
> >> opening AS7-1544, I need to make some corrections to properly
> >> accommodate multiple JPA persistence units sharing the same underlying
> >> cache definition or having their own.
> >>
> >> Currently, with AS 7.0/7.0.1, I think each application should have its
> >> own Infinispan cache definition.  In theory, the same cache definition
> >> could be shared if entity class names are unique across all persistence
> >> units (within apps and across different applications).  This can be
> >> accommodated currently by adding additional Infinispan configuration
> >> entries to the AS7 standalone.xml (or domain.xml).
> >>
> >> One question that I have, is could we add an additional key for
> >> identifying the 2lc cache.  The additional key that I have at the time
> >> of creating the container managed entity manager, is the "application
> >> name scoped persistence unit name" (includes the PU name and the
> >> application/containing jar name).  Perhaps that could be passed into
> >> InfinispanRegionFactory via a property representing a unique way to
> >> refer to all 2lc entries for a specific applications persistence unit
> >> definition.  I'm not sure how desirable it would be to further qualify
> >> the cache entries with this additional information (especially if it
> >> increases the payload transferred during replication).
> >>
> >> I think the alternative would be to have each application, configure
> >> their own cache definition (either to share with all applications PU or
> >> create a separate definition per PU).  This might be close to what I
> >> already described as a workaround in the
> >> http://community.jboss.org/message/620903 forum post.
> >>
> >> What do you think?
> >>
> >> Scott
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
>