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... 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-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

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

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

On 08/04/2009 06:40 PM, Brian Stansberry wrote: > Galder Zamarreno wrote: >> >> >> On 08/04/2009 06:23 PM, Brian Stansberry wrote: </snip> >>> >>> 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. Ok, so they need to be kept in separate cache instances then. Thx. </snip> >>>> >>>>> 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? No, that's not there yet. At the moment, we simply take the region name that we're passed (this defaults to entity type FQCN) and we look up a cache from cache manager with that name.

Having had a thought overnight to this, I do see the point of having that mapping though, otherwise if you have 10 entities which cache settings A and 10 entities with cache settings B, we'd be needing to implement 20 cache definitions. See below for a further discussion on your suggested mapping. > >> 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. To make sure I understand this correctly, the way I see this is the following. Assuming we have two entities: com.acme.Person and com.acme.Address and Person has a List of addresses represented by com.acme.Person.addresses: If no region name was configured, the provider would retrieve a cache using the default region names given and these are: com.acme.Person com.acme.Address com.acme.Person.addresses If region names have been configured but there're no overrides like the ones suggested by Brian, use simply the region names passed to get the caches from the cache manager. At startup, if overrides similar to this had been defined, then the overrides take over and a cache with name NoEvictionCache is looked up when building the region: hibernate.cache.infinispan.com.acme.Person.cfg=NoEvictionCache hibernate.cache.infinispan.com.acme.Address.cfg=NoEvictionCache hibernate.cache.infinispan.com.acme.Person.addresses.cfg=NoEvictionCache These overrides could have been defined using user-defined region names in which case the RegionFactory build* callbacks would be passed these and would be applied in the same way. Finally, wrt query/timestamps region names, by default, these appear to be hardcoded to org.hibernate.cache.UpdateTimestampsCache and org.hibernate.cache.StandardQueryCache. However, having had a look at the code, both UpdateTimestampsCache and StandardQueryCache, could have a cache region prefix configured, so my initial idea of simply using their FQCNs as cache names might not always work. So, we do need some properties here too: hibernate.cache.infinispan.cfg.timestamps=UpdateTimestampsCache hibernate.cache.infinispan.cfg.query=StandardQueryCache Then we'd have caches names with UpdateTimestampsCache and StandardQueryCache. >>>> >>>>> >>>>> Cheers >>>>> -- >>>>> Manik Surtani >>>>> manik(a)jboss.org <mailto:manik@jboss.org> >>>>> Lead, Infinispan >>>>> Lead, JBoss Cache >>>>> http://www.infinispan.org >>>>> http://www.jbosscache.org >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > >

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.

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

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,

Hi Brian, Of my original email, there's a section that I don't think has been answered yet On 08/04/2009 10:37 AM, Galder Zamarreno wrote: > 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? This question focuses on the TimestampsRegionImpl (and potentially ClusteredConcurrentTimestampsRegionImpl) work done for JBC 2.x/3.x integration layer. Is there a need for a similar region implementation for Infinispan? I'm not sure I fully understand the need for TimestampsRegionImpl to manage this local cache. Talking about timestamps, I assume that no evictions should ever happen for the timestamps cache and this is something that could be validated on startup, that eviction strategy is NONE.

Cheers,

On 08/13/2009 06:27 AM, Galder Zamarreno wrote: > Hi Brian, > > Of my original email, there's a section that I don't think has been > answered yet > > On 08/04/2009 10:37 AM, Galder Zamarreno wrote: >> 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, > > This question focuses on the TimestampsRegionImpl (and potentially > ClusteredConcurrentTimestampsRegionImpl) work done for JBC 2.x/3.x > integration layer. Is there a need for a similar region implementation > for Infinispan? I'm not sure I fully understand the need for > TimestampsRegionImpl to manage this local cache. > Timestamps caching has different semantics than the other types, hence the different region impl. I don't know any reason why that wouldn't be the case with Infinispan. It's not a "local cache"? It's replicated.

> Talking about timestamps, I assume that no evictions should ever happen > for the timestamps cache and this is something that could be validated > on startup, that eviction strategy is NONE. > +1. > Cheers,