Got distracted and hit send early last time... Brian Stansberry wrote: > Manik Surtani wrote: >> >> On 4 Aug 2009, at 14:02, Galder Zamarreno wrote: >> >>>> >>>> s/region.ispn4/infinispan >>> >>> Ok. >>> >>> One thing here though. Chris's original solution works in such way >>> that for each entity/collection, a new cache is retrieved from the >>> cache manager using the region name, so for this example 3 caches >>> would be created: >>> >>> Cache1 for >>> [org.hibernate.test.cache.infinispan.functional.VersionedItem] >>> Cache2 for [org.hibernate.test.cache.infinispan.functional.Item] >>> Cache2 for [org.hibernate.test.cache.infinispan.functional.Item.items] >>> >>> Can we confirm this is the intented way? In >>> https://jira.jboss.org/jira/browse/ISPN-6 the following is mentioned: >>> >>> "Use a separate named cache per entity. This cache would hold entity >>> instances as well as collections pertaining to that entity." >>>
In the JBC2 integration, the JBC Region is pretty important, beyond eviction. There are things like clear operations that are scoped to the Region (e.g. to support invalidating all entities of a given type out of the cache). The Infinispan integration will have the same use cases, and AIUI a cache is the semi-analogue to a JBC Region, so I think you need a cache per entity type. Also, unless there's a really good reason not too, let's try to keep things logically the same between the Infinispan and JBC integrations. Makes maintenance much easier. >>> So, if that is followed and we bear in mind the above example, there >>> should only be 2 cache instances created rather than the current 3. >>> >>> What is clear is that there's no need for >>> hibernate.cache.infinispan.cfg.entity or >>> hibernate.cache.region.ispn4.cfg.collection. Simply stick the default >>> cache configuration for entity/collections in the default section of >>> configuration. >>> > > Yeah, I've never found a good use case for using different configs for > the two. Perhaps eviction > >>> I don't we need hibernate.cache.infinispan.cfg.query and >>> hibernate.cache.infinispan.cfg.timestamps either since we can simply >>> name the caches with the corresponding region names >>> (org.hibernate.cache.UpdateTimestampsCache]and >>> org.hibernate.cache.StandardQueryCache) and that's it. >> > > The hibernate.cache.infinispan.cfg.query and > hibernate.cache.infinispan.cfg.timestamps properties aren't used to name > the caches. They specify what config to use. > >> I suppose that would depend on the need for different eviction >> characteristics for different entity types. So from that perspective >> (the ability to use) a different cache per entity is useful. >> >> E.g., >> >> NoEvictionCache for [CountryList] >> NoEvictionCache for [SomeOtherDropDown] >> AggressivelyEvictedLRUCache for [Users] >> AggressivelyEvictedLRUCache for [Orders] >> LargeCapacityFIFOCache for [ProductsCatalog] >> >> etc. may well prove useful. >> Brian/Steve - care to chime in? > > hehe, I kinda just somewhat did on another branch of the thread. W/ JBC, > different eviction per entity type could be configured via the JBC > config, using eviction regions. Seems we've lost that, unless > SessionFactory properties are added that tell the RegionFactory what > Infinispan config to use on a more fine-grained basis than "entity", > "collection", "query", "timestamp". This could perhaps be done by using > "entity", "query" as default values and allowing replacement/extension > to override the default for a particular region name. > > hibernate.cache.infinispan.CountryList.cfg=NoEvictionCache > > The ugly bit is that works if people configure a region name for their > entities, rather than using the default fully qualified class name. I > suppose the fully qualified class name could work as well, just a bit > more parsing. > >> >> Cheers >> -- >> Manik Surtani >> ma...@jboss.org <mailto:ma...@jboss.org> >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> > > -- Brian Stansberry Lead, AS Clustering JBoss by Red Hat _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
