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<smar...@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@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
