Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
On 4 Aug 2009, at 09:37, Galder Zamarreno wrote: Hi, Re: https://jira.jboss.org/jira/browse/ISPN-6 Source code for this is currently located in an Infinispan branch in the Hibernate SVN repo: https://svn.jboss.org/repos/hibernate/core/branches/INFINISPAN/ http://anonsvn.jboss.org/repos/hibernate/core/branches/INFINISPAN/ I've picked this JIRA from Chris Bredesen. I'm waiting to get an answer to an email I sent him yesterday but in the mean time, here's a list of TODOs: 1. Current Infinispan region factory needs to point to a config with named caches. Suggested property name: hibernate.cache.region.ispn4.configs hibernate.cache.infinispan.cfg ? - why do we need 'region' in there, non-intuitive to end-users? - I'd rather use infinispan rather than ispn. 2. Need a equivalent version of this region factory where cache manager is retrieved from JNDI. Suggsted property name: hibernate.cache.region.ispn4.manager s/region.ispn4/infinispan 3. Configuration properties for named cache names. Suggested property names: hibernate.cache.region.ispn4.cfg.entity hibernate.cache.region.ispn4.cfg.collection hibernate.cache.region.ispn4.cfg.query hibernate.cache.region.ispn4.cfg.timestamps s/region.ispn4/infinispan 4. Resolve TransactionalAccess, ReadOnlyAccess and BaseRegion TODOs. 5. Enhance query results region so that query changes are not propagated if invalidation is used and add query.localonly equivalent property. Suggested name: hibernate.cache.region.ispn4.query.localonly s/region.ispn4/infinispan 6. Add more unit tests! 7. Document in wiki. Good stuff, thanks for taking this on! - Manik Some notes I've made while investigating this: - Whereas with JBC2/3, we had the possibility of a shared cache for all types (entities, collections, query,...etc) and a multiplexed version where each type had a specific cache, in Infinispan, it only makes the latter. Amongst other reasons because we don't have eviction regions any more and so we can't exclude the timestamp modification region as we did in JBC2/3. Overall, having a single option is a good thing from a configuration and usability perspective! Remember how complex eviction region definition could get for entities... Finally, a question to the list, specially for Brian/Steve who worked on the JBC2/3 integration layer: - Do we need a similar timestamp region local cache implementation for an ISPN based cache provider? Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-...@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
On 08/04/2009 11:32 AM, Manik Surtani wrote: On 4 Aug 2009, at 09:37, Galder Zamarreno wrote: Hi, Re: https://jira.jboss.org/jira/browse/ISPN-6 Source code for this is currently located in an Infinispan branch in the Hibernate SVN repo: https://svn.jboss.org/repos/hibernate/core/branches/INFINISPAN/ http://anonsvn.jboss.org/repos/hibernate/core/branches/INFINISPAN/ I've picked this JIRA from Chris Bredesen. I'm waiting to get an answer to an email I sent him yesterday but in the mean time, here's a list of TODOs: 1. Current Infinispan region factory needs to point to a config with named caches. Suggested property name: hibernate.cache.region.ispn4.configs hibernate.cache.infinispan.cfg ? - why do we need 'region' in there, non-intuitive to end-users? - I'd rather use infinispan rather than ispn. Ok, fair enough. 2. Need a equivalent version of this region factory where cache manager is retrieved from JNDI. Suggsted property name: hibernate.cache.region.ispn4.manager s/region.ispn4/infinispan Ok 3. Configuration properties for named cache names. Suggested property names: hibernate.cache.region.ispn4.cfg.entity hibernate.cache.region.ispn4.cfg.collection hibernate.cache.region.ispn4.cfg.query hibernate.cache.region.ispn4.cfg.timestamps 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. 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. 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. 4. Resolve TransactionalAccess, ReadOnlyAccess and BaseRegion TODOs. 5. Enhance query results region so that query changes are not propagated if invalidation is used and add query.localonly equivalent property. Suggested name: hibernate.cache.region.ispn4.query.localonly s/region.ispn4/infinispan Ok. 6. Add more unit tests! 7. Document in wiki. Good stuff, thanks for taking this on! You're welcome :) - Manik Some notes I've made while investigating this: - Whereas with JBC2/3, we had the possibility of a shared cache for all types (entities, collections, query,...etc) and a multiplexed version where each type had a specific cache, in Infinispan, it only makes the latter. Amongst other reasons because we don't have eviction regions any more and so we can't exclude the timestamp modification region as we did in JBC2/3. Overall, having a single option is a good thing from a configuration and usability perspective! Remember how complex eviction region definition could get for entities... Finally, a question to the list, specially for Brian/Steve who worked on the JBC2/3 integration layer: - Do we need a similar timestamp region local cache implementation for an ISPN based cache provider? Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-...@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
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. 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. 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. 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? Cheers -- Manik Surtani ma...@jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
On Tue, 2009-08-04 at 14:35 +0100, Manik Surtani wrote: Yes this is obviously something worthwhile at a high level. I cannot speak to implementation details wrt Infinispan. 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. -- Steve Ebersole st...@hibernate.org Hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
Galder Zamarreno wrote: Hi, Re: https://jira.jboss.org/jira/browse/ISPN-6 Source code for this is currently located in an Infinispan branch in the Hibernate SVN repo: https://svn.jboss.org/repos/hibernate/core/branches/INFINISPAN/ http://anonsvn.jboss.org/repos/hibernate/core/branches/INFINISPAN/ I've picked this JIRA from Chris Bredesen. I'm waiting to get an answer to an email I sent him yesterday but in the mean time, here's a list of TODOs: 1. Current Infinispan region factory needs to point to a config with named caches. Suggested property name: hibernate.cache.region.ispn4.configs 2. Need a equivalent version of this region factory where cache manager is retrieved from JNDI. Suggsted property name: hibernate.cache.region.ispn4.manager 3. Configuration properties for named cache names. Suggested property names: hibernate.cache.region.ispn4.cfg.entity hibernate.cache.region.ispn4.cfg.collection hibernate.cache.region.ispn4.cfg.query hibernate.cache.region.ispn4.cfg.timestamps 4. Resolve TransactionalAccess, ReadOnlyAccess and BaseRegion TODOs. 5. Enhance query results region so that query changes are not propagated if invalidation is used and add query.localonly equivalent property. Suggested name: hibernate.cache.region.ispn4.query.localonly 6. Add more unit tests! 7. Document in wiki. Some notes I've made while investigating this: - Whereas with JBC2/3, we had the possibility of a shared cache for all types (entities, collections, query,...etc) and a multiplexed version where each type had a specific cache, in Infinispan, it only makes the latter. Amongst other reasons because we don't have eviction regions any more and so we can't exclude the timestamp modification region as we did in JBC2/3. Overall, having a single option is a good thing from a configuration and usability perspective! Remember how complex eviction region definition could get for entities... Is this basically a configuration issue? I.e. the eviction would have to be configured via Hibernate SessionFactory properties, since the Infinispan config file can't express it? That's unfortunate, as it means different entity types can't have different eviction behavior. The timestamps could be handled programatically; the Hib/Ispn integration knows it's dealing with timestamps. All that said, I have no problem with eliminating the possibility of a shared cache. There is no legacy usage to support like there was with JBC2. And if people want a shared cache, we can revisit. Finally, a question to the list, specially for Brian/Steve who worked on the JBC2/3 integration layer: - Do we need a similar timestamp region local cache implementation for an ISPN based cache provider? Sorry, I don't understand the question. Cheers, -- 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
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
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. 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
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
On 08/04/2009 03:35 PM, 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. 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. 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. 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. That's already doable. I mean, you can have a named cache with the FQCN of the class and that means that when a region for that entity is created, it will pick the named cache with the specific eviction policies. Brian/Steve - care to chime in? Cheers -- Manik Surtani ma...@jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
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
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
On 08/04/2009 06:23 PM, Brian Stansberry wrote: 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. + 1 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. Assuming that org.hibernate.test.cache.infinispan.functional.Item.items is a Collection belonging to org.hibernate.test.cache.infinispan.functional.Item, do you agree on keeping each in a separate cache? 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? No, we haven't lost it at all. You can define a cache with specific eviction settings and give it as name the FQCN of the entity and that's done. The problem though is that for each Collection this entity has, you'd need a separate cache instance since at the moment, an entity's collection is stored in a separate cache. So, if Person has several Address instances, Person will be one cache instance and his/hers addresses would be stored in a different cache instance. 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 -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
Galder Zamarreno wrote: On 08/04/2009 06:23 PM, Brian Stansberry wrote: 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. + 1 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. Assuming that org.hibernate.test.cache.infinispan.functional.Item.items is a Collection belonging to org.hibernate.test.cache.infinispan.functional.Item, do you agree on keeping each in a separate cache? Yes. With JBC they are separate Regions. We need the ability to scope things like clear commands to the data hibernate is working with, and an entity and its associated collections are separate things to hibernate. 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? No, we haven't lost it at all. You can define a cache with specific eviction settings and give it as name the FQCN of the entity and that's done. How is this configured by the end user? I mean the mapping from the entity type to the cache config name. Is something like what I described below implemented already? The problem though is that for each Collection this entity has, you'd need a separate cache instance since at the moment, an entity's collection is stored in a separate cache. So, if Person has several Address instances, Person will be one cache instance and his/hers addresses would be stored in a different cache instance. True. Although this is only an issue if you wanted separate eviction. Hibernate allows you to specify a region name for any cachable item (except timestamps). The use of FQCN is just a default for people who don't want to configure things. 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
