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.

Sanne 2011/8/16 Scott Marlow<smarlow(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

> 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? That sounds like a good plan

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?

> > Sanne > > > 2011/8/16 Scott Marlow<smarlow(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>

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. Sanne 2011/8/16 Scott Marlow <smarlow(a)redhat.com&gt;: > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev