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(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
>>