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

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 manik(a)jboss.org <mailto:manik@jboss.org> Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org

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 >> manik(a)jboss.org <mailto:manik@jboss.org> >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> > >

Galder Zamarreno wrote: > > > On 08/04/2009 06:23 PM, Brian Stansberry wrote:

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

>>> >>>> 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 qualified class name. I >>> suppose the fully qualified class name could work as well, just a bit >>> more parsing.

>>> >>>> >>>> Cheers >>>> -- >>>> Manik Surtani >>>> manik(a)jboss.org <mailto:manik@jboss.org> >>>> Lead, Infinispan >>>> Lead, JBoss Cache >>>> http://www.infinispan.org >>>> http://www.jbosscache.org >>>> >>>> >>>> >>>> >>> >>> >> >> >

Galder Zamarreno wrote: >

> Sounds like this has diverged quite a bit from the JBC integration then. In your initial message you were discussing 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 What were those to be used for? With JBC they identify the name of a cache configuration, which is used to obtain an appropriately configured org.jboss.cache.Cache from the JBC CacheManager. My assumption on this thread was the same basic approach would be used with Infinispan. The "region name" that Hibernate passes is not meant to be the name of the cache configuration. It could be a unique identifier for the cache that's created using that configuration, but it's not the name of the configuration.

If you follow that approach, you use the above properties to establish defaults for each of the 4 data types. You then use the techniques you discuss below to override those defaults if people need specialized configs for certain entities.

Semi-tangent: in general I really dislike if people have to configure JBC/Infinispan to get standard behaviors (e.g. eviction). Much better if people can use the standard configuration mechanism of whatever service is using JBC/Infinispan, and only touch JBC/Infinispan configs for exotic stuff. So, for example, web session passivation is configured via jboss-web.xml, not via a JBC eviction region. If the properties needed to configure 2nd Level Cache eviction could be reduced to 2 or 3, being able to express them via the SessionFactory config would be nice, e.g. hibernate.cache.infinispan.Users.max_age=5000 Perhaps just support LRU that way; if people want exotic stuff beyond LRU they have to go to the Infinispan config.

On 08/05/2009 06:52 PM, Brian Stansberry wrote: > Galder Zamarreno wrote: >> >> >> On 08/05/2009 04:04 PM, Brian Stansberry wrote: >>> Galder Zamarreno wrote: >>>> >> </snip> >>>> >>> >>> Sounds like this has diverged quite a bit from the JBC >>> integration then. >>> In your initial message you were discussing 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 >>> >>> What were those to be used for? With JBC they identify the name >>> of a >>> cache configuration, which is used to obtain an appropriately >>> configured >>> org.jboss.cache.Cache from the JBC CacheManager. My assumption on >>> this >>> thread was the same basic approach would be used with Infinispan. >>> The >>> "region name" that Hibernate passes is not meant to be the name >>> of the >>> cache configuration. It could be a unique identifier for the cache >>> that's created using that configuration, but it's not the name of >>> the >>> configuration. >> >> Those names are not yet in use. They're just initial suggestions I >> had >> in mind to map JBC2/3 cache integration to ISPN. Shortly after I >> realised that actually, for each entity/collection, a cache was >> being >> created. >> >>> >>> If you follow that approach, you use the above properties to >>> establish >>> defaults for each of the 4 data types. You then use the >>> techniques you >>> discuss below to override those defaults if people need specialized >>> configs for certain entities. >> >> And I suppose that using those 4 properties follows the same kind of >> default pattern as previous cache integration layer which is a good >> thing. >> > > Cool. Being able to configure different caches per entity type will > be > kinda nice. > > Semi-tangent: in general I really dislike if people have to configure > JBC/Infinispan to get standard behaviors (e.g. eviction). Much > better if > people can use the standard configuration mechanism of whatever > service > is using JBC/Infinispan, and only touch JBC/Infinispan configs for > exotic stuff. So, for example, web session passivation is > configured via > jboss-web.xml, not via a JBC eviction region. > > If the properties needed to configure 2nd Level Cache eviction > could be > reduced to 2 or 3, being able to express them via the SessionFactory > config would be nice, e.g. > > hibernate.cache.infinispan.Users.max_age=5000 > > Perhaps just support LRU that way; if people want exotic stuff beyond > LRU they have to go to the Infinispan config. I like the idea a lot. This would limit the number of files to modify for the most commonly touched things to 1 and that's a great thing from a usability perspective. I think this is very doable as well since ISPN has good support programmatic configuration (see http://www.jboss.org/community/wiki/infinispan-eviction) Infinispan has currently 5 settings in total for eviction/expiration and so they're little enough that we support them all, i.e. hibernate.cache.infinispan.entity.strategy=LRU hibernate.cache.infinispan.entity.wake_up_interval=2000 hibernate.cache.infinispan.entity.max_entries=5000 hibernate.cache.infinispan.entity.lifespan=60000 // equivalent of maxAge hibernate.cache.infinispan.entity.max_idle=30000 // equivalent of timeToLive

FYI: I've summarised the agreed points in https://jira.jboss.org/jira/browse/ISPN-6 and shortened a bit the configuration properties (removed .cfg. in the named cache properties).

On 7 Aug 2009, at 12:51, Galder Zamarreno wrote: > Manik, > > While I working on this, I've noted the following. If we define > default cache configurations for entity/query/...etc in an infinispan > configuration file, currently, they cannot be overriden afterwards > programatically. > > IOW, imagine there's a cache named "entity" that applies to all > entities in a sample infinispan-configs.xml and then someone tweaks it > in the hibernate config like this: > > hibernate.cache.infinispan.entity.eviction.wake_up_interval=3000 > > The way I'd deal with this is that I'd create a Configuration with > this new interval and call defineCache("entity", cfg). However, when > the configuration file was processed, "entity" cache was added to the > configuration overrides and hence when I call defineCache with > "entity", it throws DuplicateCacheNameException. > > So, I think DFC.initialize() shouldn't add such configurations to > configuration overridesm map. > > Thoughts? Hmm. Perhaps what is needed is a mechanism to retrieve these configurations and alter them. E.g., CacheManager.getConfiguration(); // retrieves the default cfg CacheManager.getConfiguration(String name);

These Configuration objects - built based on what's in the XML file - can then be tweaked. These should be adequately javadoc'd to make it clear that caches already started using such a configuration will not be affected when a configuration changes.

I guess this also renders CacheManager.defineCache() API useless/obsolete, since getConfiguration() should always return a configuration, even if one didn't exist /wasn't defined in XML.

Cheers Manik -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org

On 8 Aug 2009, at 08:14, Galder Zamarreno wrote: > > On 08/07/2009 02:06 PM, Manik Surtani wrote: >> >> On 7 Aug 2009, at 12:51, Galder Zamarreno wrote: >> >>> Manik, >>> >>> While I working on this, I've noted the following. If we define >>> default cache configurations for entity/query/...etc in an infinispan >>> configuration file, currently, they cannot be overriden afterwards >>> programatically. >>> >>> IOW, imagine there's a cache named "entity" that applies to all >>> entities in a sample infinispan-configs.xml and then someone tweaks it >>> in the hibernate config like this: >>> >>> hibernate.cache.infinispan.entity.eviction.wake_up_interval=3000 >>> >>> The way I'd deal with this is that I'd create a Configuration with >>> this new interval and call defineCache("entity", cfg). However, when >>> the configuration file was processed, "entity" cache was added to the >>> configuration overrides and hence when I call defineCache with >>> "entity", it throws DuplicateCacheNameException. >>> >>> So, I think DFC.initialize() shouldn't add such configurations to >>> configuration overridesm map. >>> >>> Thoughts? >> >> Hmm. Perhaps what is needed is a mechanism to retrieve these >> configurations and alter them. E.g., >> >> CacheManager.getConfiguration(); // retrieves the default cfg >> CacheManager.getConfiguration(String name); > > Yeah, without starting the cache! Right now, the only way to get a > configuration is after doing manager.getCache() which effectively > starts the cache and hence, the Configuration's ComponentRegistry is > in RUNNING mode, so you can't just clone it and modify it to be used > somewhere else. Even the clone is in running state and didn't find an > easy way to change that. > > There's a second possibility here too: My above suggestion won't just > work cos what defineCache("entity", cfg) does is take the *default* > cache configuration, apply the overrides and create one with name > "entity". But I want to do is: take the "entity" named cache > configuration, apply the overrides and create a brand new one with the > same name "entity". So, a method like this: > > defineCache(String cacheName, String baseNamedCache, Configuration > overrides). That would work as well. Javadocs need to be clear though as to what is cloned and ready for use, etc. > > So, then apart from doing defineCache("entity", "entity", overrides), > I could also do defineCache("com.acme.Person", "entity", overrides). > The latter would define a cache for com.acme.Person entity type, based > on "entity" named cache and applying overrides defined via > hibernate.cfg.xml > >> >> These Configuration objects - built based on what's in the XML file - >> can then be tweaked. These should be adequately javadoc'd to make it >> clear that caches already started using such a configuration will not be >> affected when a configuration changes. > > Indeed, getConfiguration() would return clones who's running state has > been cleared. Maybe Configuration.clone() should already be doing that? This should be true as well. The state should never be cloned.

> >> >> I guess this also renders CacheManager.defineCache() API >> useless/obsolete, since getConfiguration() should always return a >> configuration, even if one didn't exist /wasn't defined in XML. > > Yeah, it's either enhanced defineCache() or getConfiguration(). I > think CacheManager.getConfiguration() is likely to be a more powerful > and simpler API than defineCache(*). Well, I think we need both. getConfiguration(String name) to retrieve a configuration template and modify it. defineCache(String newName, String templateName, Configuration overrides) to create a new configuration based on an existing one. Maybe this name should change to something more intuitive? Perhaps instead of defineCache, we have: Configuration defineConfiguration(String configurationName, Configuration overrides) // registers and names a NEW configuration, based on the default cfg and the overrides passed in Configuration defineConfiguration(String configurationName, String templateName, Configuration overrides) // registers and names a NEW configuration, based on an existing, predefined configuration and the overrides passed in WDYT?

Cheers -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org

On 08/10/2009 01:09 PM, Galder Zamarreno wrote: > > On 08/10/2009 12:42 PM, Manik Surtani wrote: </snip> >> Well, I think we need both. >> >> getConfiguration(String name) to retrieve a configuration template >> and >> modify it. >> defineCache(String newName, String templateName, Configuration >> overrides) to create a new configuration based on an existing one. >> Maybe >> this name should change to something more intuitive? Perhaps >> instead of >> defineCache, we have: >> >> Configuration defineConfiguration(String configurationName, >> Configuration overrides) // registers and names a NEW configuration, >> based on the default cfg and the overrides passed in >> >> Configuration defineConfiguration(String configurationName, String >> templateName, Configuration overrides) // registers and names a NEW >> configuration, based on an existing, predefined configuration and >> the >> overrides passed in >> >> WDYT? > > That would be a great way to combine the two API requirements. I > assume > that the returned Configuration instances returned would have had the > overrides applied to them already. > > Let me work on this APIs in parallel to the work I'm doing for > ISPN-6 so > that I can fully exercise/test and see if there's anything we'd > need to > change. > > https://jira.jboss.org/jira/browse/ISPN-152 A quick update on this. I have implemented ISPN-152, integrated it with the cache provider and the tests I have are now passing. Just a heads up on a change of behaviour. defineConfiguration(*) methods do no longer throw DuplicateCacheNameException since this limits the API a lot disabling any type of configuration redefininitions/overriding. Example: defineConfiguration("entity", "entity", overrides); This means, take the configuration for named cache "entity", apply overrides and use that as new "entity" cache name configuration. If we're throwing DuplicateCacheNameException(s), we wouldn't be able to do this and this seems like a valid use case to me. By the way, I've already noted this in the javadoc but doing the following: Configuration c = defineConfiguration("entity", new Configuration()); is a way to return "entity" named cache's configuration! (equivalent to doing something like: manager.getConfiguration("entity") if such method existed!) IOW, this defineConfiguration method is saying: "define a configuration, based on "entity" and apply no overrides (cos no setters have been called in the Configuration instance!) and return new configuration instance" I've detailed all this in CacheManager's javadoc that you can find attached. If you get the chance, have a read to it and let me know if anything is not clear enough.

On 08/11/2009 05:42 PM, Manik Surtani wrote: > > On 11 Aug 2009, at 16:34, Galder Zamarreno wrote: > >> >> >> On 08/10/2009 01:09 PM, Galder Zamarreno wrote: >>> >>> On 08/10/2009 12:42 PM, Manik Surtani wrote: >> >> </snip> >> >>>> Well, I think we need both. >>>> >>>> getConfiguration(String name) to retrieve a configuration >>>> template and >>>> modify it. >>>> defineCache(String newName, String templateName, Configuration >>>> overrides) to create a new configuration based on an existing one. >>>> Maybe >>>> this name should change to something more intuitive? Perhaps >>>> instead of >>>> defineCache, we have: >>>> >>>> Configuration defineConfiguration(String configurationName, >>>> Configuration overrides) // registers and names a NEW >>>> configuration, >>>> based on the default cfg and the overrides passed in >>>> >>>> Configuration defineConfiguration(String configurationName, String >>>> templateName, Configuration overrides) // registers and names a >>>> NEW >>>> configuration, based on an existing, predefined configuration >>>> and the >>>> overrides passed in >>>> >>>> WDYT? >>> >>> That would be a great way to combine the two API requirements. I >>> assume >>> that the returned Configuration instances returned would have had >>> the >>> overrides applied to them already. >>> >>> Let me work on this APIs in parallel to the work I'm doing for >>> ISPN-6 so >>> that I can fully exercise/test and see if there's anything we'd >>> need to >>> change. >>> >>> https://jira.jboss.org/jira/browse/ISPN-152 >> >> A quick update on this. I have implemented ISPN-152, integrated it >> with the cache provider and the tests I have are now passing. Just a >> heads up on a change of behaviour. >> >> defineConfiguration(*) methods do no longer throw >> DuplicateCacheNameException since this limits the API a lot >> disabling >> any type of configuration redefininitions/overriding. Example: >> >> defineConfiguration("entity", "entity", overrides); >> >> This means, take the configuration for named cache "entity", apply >> overrides and use that as new "entity" cache name configuration. If >> we're throwing DuplicateCacheNameException(s), we wouldn't be able >> to >> do this and this seems like a valid use case to me. >> >> By the way, I've already noted this in the javadoc but doing the >> following: >> >> Configuration c = defineConfiguration("entity", new >> Configuration()); >> >> is a way to return "entity" named cache's configuration! (equivalent >> to doing something like: manager.getConfiguration("entity") if such >> method existed!) IOW, this defineConfiguration method is saying: >> "define a configuration, based on "entity" and apply no overrides >> (cos >> no setters have been called in the Configuration instance!) and >> return >> new configuration instance" >> >> I've detailed all this in CacheManager's javadoc that you can find >> attached. If you get the chance, have a read to it and let me know >> if >> anything is not clear enough. > > Most of it sounds good, but the javadoc on defineConfiguration() is a > bit misleading. > > " * <p/> > * If cache name hasn't been defined before, this method creates a > clone > of the configuration of the cache whose > * name matches the given template cache name, then applies the > configuration overrides passed and returns this > * configuration instance. > * <p/> > * If cache name has been previously defined, this method creates a > clone > of this cache's existing configuration, > * applies the overrides and return this configuration instance. > * <p/>" > > The first bit makes sense. The second bit though, I would expect the > behaviour to be to clone the template cfg, apply changes, and > overwrite > the existing named config rather than use the existing named config > as > the template (rather than templateCacheName). Hmmm, right, so defineConfiguration(String, String, Configuration) should work the same way regardless of whether the configuration for the named cache exists or not, correct? In both cases, a clone a clone of the template cache's configuration would be made, apply a clone of the overrides, and overwrite existing named cache's configuration.

In fact, a side thing, this has reminded my that "then applies the configuration overrides passed" should say "then applies a clone of the configuration overrides passed in", this makes it clear that the configuration passed in cannot be modified after calling defineConfiguration() and expect its changes to be reflected in the CacheManager.

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 manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org